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1.0  SUMMARY 


The  Air  Force  Research  Laboratory’s  (AFRL)  711*  Human  Performance  Wing  Human 
Effectiveness  Directorate  (711  HPW/RHCP)  created  the  Human  Effectiveness  in  the  Air  & 

Space  Operations  Center  (HE  in  the  AOC)  program  to  address  warfighter  work  challenges 
experienced  in  the  AOC  Strategy  Division  (SD).  The  research  goal  was  to  develop  a  thorough 
understanding  of  warfighter  information  and  decision  requirements  within  the  SD  and  to 
organizations  within  and  beyond  the  AOC  in  order  to  better  support  warfighter  decision  making, 
affordances  and  interactions. 

Phase  I  of  HE  in  the  AOC  was  conducted  by  ManTech  Aegis  and  involved  a  decision-focused 
analysis  of  AOC  SD  personnel.  The  resulting  AOC  Cognitive  Work  Requirements  product 
served  as  a  jumpstart  for  formalizing  user  information  and  decision  requirements.  Phase  II  of  HE 
in  the  AOC  consisted  of  parallel  efforts.  One  effort,  Strategy  Planning  Visualization  Tool 
(SPVT),  was  tasked  with  bringing  decision-centered  visualization  support  to  the  Strategy 
Division  Strategy  Planning  Team  (SPT),  while  the  parallel  effort.  Operational  Effects 
Assessment  Visualization  Tool  (OEAVT),  was  tasked  with  bringing  decision-centered 
visualization  support  to  the  Strategy  Division  Operational  Assessment  Team  (OAT).  OEAVT 
was  performed  by  Science  Applications  International  Corporation  (SAIC)  under  a  separate 
contract. 

SPVT  extended  the  information  contained  in  the  AOC  SD  Phase  I  Cognitive  Task  Analysis 
(CTA)  by  conducting  analyses  and  performing  additional  interviews  with  warfighters.  The 
interaction  with  warfighters  was  used  to  ensure  the  team  had  a  solid  understanding  of  the  CTA, 
to  further  develop  upon  knowledge  of  work  in  the  AOC  SD  and  to  refine  concepts  and 
prototypes.  The  effort  yielded  an  extensive  body  of  knowledge  for  the  AOC  SD  and  resulted  in 
two  prototypes,  transitioning  into  Air  Force  programs  of  record. 
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2.0  INTRODUCTION 


The  primary  dimensions  addressed  under  SPVT’s  decision-centered  analysis  in  the  AOC  SD 
included  the  following: 

•  How  decisions  are  made  in  performing  work 

•  How  work  products  are  developed 

•  How  work  is  managed 

•  The  types  of  collaborations  and  interactions  that  are  necessary 

This  knowledge  came  in  part  from  the  Phase  I  AOC  Cognitive  Work  Requirements  which  were 
used  as  a  basis  for  the  cognitive  and  collaboration  work  requirements  for  the  work-centered 
support  visualization  efforts  described  herein. 

Products  from  SPVT  were  designed  to  operate  with  the  related  and  envisioned  information, 
applications,  systems,  and  infrastructure  planned  to  be  delivered  with  the  AOC  Block  10.2  and 
Joint  capabilities,  such  as: 

•  Information  Warfare  Planning  Capability  (IWPC) 

•  Information  Operations  Planning  Capability  -  Joint  (lOPC-J) 

•  Virtual  Integrated  Support  for  the  Information  Operations  Environment  (VisIOn) 

•  Global  Operations  Center  Collaborative  Environment  (GOC-CE) 

•  Theater  Battle  Management  Core  Systems  (TBMCS)/Theater  Battle  Operations  Net¬ 
centric  Environment  (TBONE) 

•  Modernized  Integrated  Database  (MIDB) 

•  Joint  Targeting  Tool  (JTT) 

SPVT  was  comprised  of  several  tasks.  The  initial  sequence  of  tasks  followed  a  human-centered 
systems  engineering  process  from  user  requirements  to  system  concept  and  definition  through 
system  prototype  and  evaluation.  The  initial  task  focused  on  understanding  (Section  3.1)  User 
Information  and  Decision  Requirements  in  the  work  context  for  AOC  SD  personnel  (see 
Section  3.1).  The  understanding  was  accomplished  across  the  SD  for  the  SPT,  Strategy  Guidance 
Team  (SGT)  and  OAT. 

The  first  task  to  leverage  user  requirements  understanding  was  the  (Section  3.2)  Common 
Effects  Picture  (CEP).  CEP  started  as  a  dashboard  or  high-level  visualization  concept  for  senior 
AOC  leaders  such  as  an  AOC  Director  or  Joint  Forces  Air  Component  Commander  (JFACC)  to 
quickly  assess  the  battlespace  and  develop  understanding.  The  task  evolved  by  incorporating 
one-  and  two-level  decomposition  (drill-down)  into  more  detailed  views  on  the  information. 
These  additional  views  were  intended  to  provide  the  senior  leaders  a  capability  to  understand, 
when  necessary,  the  elements  comprising  a  particular  condition  or  state  and  to  serve  as  the 
operating  environment  for  the  supporting  staff. 

The  CEP  concept  was  used  as  a  launch  pad  for  the  (Section  3.3)  Global  Effects  Management  - 
Synchronization  (GEM-S)  task.  The  joint  community  expressed  an  interest  in  a  concept  to 
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visualize  Department  of  Defense  (DoD)  operations  and  effects  by  organization,  important 
operational  dependencies  and  relationships,  and  timing,  all  on  a  global  scale.  While  conceptually 
the  prototype  provided  an  informative  view  onto  operations  at  a  large  scale,  the  care  and  feeding 
of  the  tool  through  data  feeds  and  manual  inputs  appeared  to  be  a  major  undertaking.  GEM-S, 
however,  brought  forth  several  visualization  concepts  for  portraying  operational  effects.  These 
concepts  carried  forward  to  other  technology  concepts. 

The  next  task,  the  (Section  3.4)  Joint  Air  Operations  Plan  (JAOP)  Air  Operations  Directive 
(AOD)  Status  Tool  (JAST)  was  the  product  of  a  need  to  complete  a  significant  feedback  path 
from  Combat  Operations  (CO)  to  the  SD.  The  SD  produces  the  AOD  which  is  used  to  develop 
the  daily  Air  Tasking  Order  (ATO).  Often,  information  regarding  whether  a  mission  on  the 
current  ATO  was  1)  scheduled,  and  2)  executed,  is  unknown  through  SD’s  next  iteration  of  the 
AOD.  The  missing  information  requires  the  SD  to  re-plan  a  mission  or  missions  whose  execution 
status  is  unknown  in  order  to  ensure  the  tactical  goal  (effect)  is  achieved.  The  opportunity  to 
complete  this  feedback  path  was  realized  with  the  inception  of  TBONE. 

The  SPVT  team  re-engaged  supporting  work  in  the  AOC  SD,  but  this  time  with  a  renewed 
sensitivity  to  the  data  feeds  supporting  a  prototype  technology.  The  team’s  focus  turned  to 
assisting  the  strategy  planner  in  capturing  and  formulating  data  and  information  which  heretofore 
had  been  a  very  manual  and  inefficient  process.  Early  in  the  planning  process  and  when  an 
operation  changes  significantly,  the  SD  is  tasked  with  developing  one  or  more  Courses  of  Action 
(COA).  The  COA  Development  process  is  often  associated  with  the  term  ‘Bunch  of  Old  Guys 
Sitting  Around  the  Table’  (BOGSAT).  While  the  deployment  of  IWPC  to  all  Combatant 
Commands  (COCOMs)  late  in  the  SPVT  project  offered  support  to  the  manual  process,  much 
effort  would  continue  along  the  previous  path.  Figure  1  illustrates  SPVT’s  work-centered 
approach  which  focused  on  replacing  multiple  inputs/outputs/tools  and  data  translations  with  a 
single  unified  workspace  that  satisfied  work  objectives.  (Section  3.5)  COA  Sketch  offered  a 
fresh  approach  to  COA  Development,  as  well  as  support  to  other  upstream  and  downstream 
elements  of  the  JAOP  process  such  as  Mission  Analysis. 


Figure  1  SPVT  Work-Centered  Focus  to  Concept  Design  and  Refinement 
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CO  A  Sketch  continued  to  evolve  while  (Section  3.6)  TENEO  was  brought  to  the  SPVT  program 
for  evaluation  as  a  capability  enhancement  to  IWPC.  TENEO  was  a  rapid  prototype  for 
validation  of  planned  Air  Tasking  Orders.  TENEO  demonstrated  a  solid  concept  of  importing  an 
ATO  for  playback  and  threat  ring  display  against  the  ATO  missions.  TENEO,  however,  was 
initially  intended  only  as  a  proof  of  concept  with  software  methods  not  designed  for  integration 
with  other  applications.  IWPC  program  office  was  interested  in  determining  whether  TENEO 
was  mature  enough  to  integrate  quickly  with  IWPC. 

Once  COA  Sketch  gained  momentum  as  a  prototype,  more  attention  was  paid  to  the  anticipated 
data  model  requirements.  A  risk  reduction  effort  to  explore  the  feasibility  of  a  net-centric, 
ontology-based,  pluggable  architecture  to  support  a  suite  of  technologies,  (Section  3. 7) 
Information  Operations  Planning  Capability  -  Experiment  (lOPC-X),  provided  a  perfect  venue 
against  which  to  build  a  data  model  for  COA  Sketch.  Further,  lOPC-X  was  soliciting 
technologies  to  apply  within  the  “to  be”  architecture  and  COA  Sketch  fit  that  plan  well. 

Maturation  of  COA  Sketch  and  lOPC-X  required  access  to  operationally-relevant,  planning 
mission  data  sources  such  as  MIDB,  JTT  and  Friendly  Order  of  Battle  (FrOB).  Interfaces  to 
these  databases  were  developed  and  used  to  various  extents. 

The  final  task  focused  on  supporting  the  Strategy  Division  through  improved  human-machine 
and  human-human  information  exchanges.  Specifically,  the  Australian  Department  of  Defence 
Defence  Science  and  Technology  Organisation  (DSTO)  provided  LiveSpaces,  a  technology 
focused  on  support  for  (Section  3.8)  Collaboration  in  the  AOC  Context,  the  type  often  found  in 
Command  and  Control  environments.  Key  elements  of  the  LiveSpaces  environment  were 
instantiated  for  evaluation  within  an  AOC  Strategy  Planning  context.  LiveSpaces  elements  which 
were  not  immediately  available  to  instantiate  for  various  programmatic  reasons),  were 
augmented  through  development  of  similar  capability  plug-ins.  One  important  characteristic  of 
the  LiveSpaces  environment  was  the  ability  to  quickly  and  easily  develop  capability  extensions. 
This  feature  alone,  aside  from  LiveSpaces  ability  to  effectively  support  intense  collaboration, 
provided  an  excellent  framework  from  within  which  Research  &  Development  activities  are 
easily  supported. 

Ultimately,  the  combination  of  requirements  elicitation,  concept  generation  and  refinement,  and 
prototype  development  and  evaluation  resulted  in  a  large  body  of  knowledge  for  the  AOC  SD, 
several  conceptual  prototypes,  one  risk  reduction,  one  technology  demonstration  and  two 
technologies  transitioned  to  United  States  Air  Force  (USAF)  and  United  States  Strategic 
Command  (USSTRATCOM)  programs  of  record. 

The  tasks  collectively  provide  a  solid  work-centered  analysis  of  AOC  SD  processes  and 
decisions  with  several  technologies  designed  to  support  the  various  aspects  of  the  analysis.  Each 
task  is  described  in  more  detail  in  the  following  section. 
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3.0  METHODS,  ASSUMPTIONS,  AND  PROCEEDINGS 


3.1  USER  INFORMATION  AND  DECISION  REQUIREMENTS 

Initial  understanding  of  AOC  high  level  needs  were  taken  from  the  ManTeeh  AOC  Cognitive 
Work  Analysis  (CWA)  generated  in  Phase  I  (prior  to,  but  overlapping  the  SPVT  contract).  The 
SPVT  project  built  upon  the  CWA  analysis  via  a  thorough  modeling  of  the  AOC  Strategy 
Division  processes.  This  effort  provided  an  enterprise  level  view  of  the  AOC,  AOC  personnel, 
processes  and  information  flow  and  exchange  requirements.  The  effort  ensured  traceability  to  all 
sources  for  future  validation  and  clarification  of  need. 

The  analysis  included  a  literature  review  of  Air  Force  doctrine,  pamphlets  and  other  materials  as 
well  as  interviews  with  subject  matter  experts  (SMEs).  The  following  high-level  requirements 
were  generated  during  this  phase  of  the  SPVT  effort. 

•  Assist  with  COA  development  by  allowing  Strategy  Planners  to  follow  current  work 
processes 

•  Visually  represent  COAs  while  maintaining  relational  context  to  the  temporal  and  textual 
plan  elements 

•  Import  or  directly  reference  political,  environmental,  geospatial,  logistical,  informational, 
temporal  and  guidance  layered  data  elements  from  existing  tools  within  the  AOC  or  GSP 
environments 

•  Maintain  available  relationships  to  other  data  elements  both  internal  and  external  to  COA 
Sketch  for  all  imported  or  directly  referenced  data  elements 

•  Assist  with  notional  Allocation  Planning 

•  Provide  Apportionment  level  estimation  and  situational  awareness  based  upon  the 
notional  allocation 

•  Provide  temporal  estimation  capabilities  based  upon  the  notional  allocation  scheme 

•  Allow  planners  to  designate  areas  of  effect  in  a  geographical  or  conceptual  context 

•  Allow  multiple  users  to  collaborate  on  the  development  of  one  or  more  COAs 

•  Format  briefing  material  for  the  JFACC  COA  Decision  Brief 

•  Interface  to  current  planning  tools  in  order  to  automate  the  transfer  of  nominated  and 
selected  COAs 

Appendix  A  contains  more  than  500  AOC  operational  requirements  that  were  generated  during 
the  SPVT  program.  This  list  of  requirements  is  organized  chronologically  by  task  or  event 
(JAST,  CEP,  WAW,  COA  Sketch  and  high-level  COA  Sketch).  Initial  requirements  were  used 
as  a  baseline  set  for  all  future  AOC  SPVT  efforts  to  provide  a  solid  understanding  of  the 
doctrinal  point  of  view  of  the  AOC  and  SPT  to  the  SRA  SPVT  project  team.  Each  subsequent 
task  built  on  the  requirements  foundation.  The  analysis  was  particularly  useful  to  members  of  the 
SRA  elicitation  teams  when  performing  CTA  interviews  of  SMEs. 
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3.2  COMMON  EFFECTS  PICTURE 


The  initial  application  of  the  user  requirements  analysis  followed  a  request  to  develop  a  rapid 
prototype  for  a  “dashboard”  to  support  a  commander  and  staff.  The  Common  Effects  Picture  or 
CEP  was  designed  to  roll  up  effects  from  planning  and  execution  through  the  operational  level. 
CEP  provided  a  visualization  to  help  senior  decision  makers  manage  effects  based  operations. 

The  task  focused  on  requirement’s  analysis  of  a  Commander’s  decision  making,  based  in  part  on 
the  previous  “JFACC  Cognitive  Analysis”  CTA  performed  by  Aptima  under  a  separate  contract. 
Key  requirements  included  the  following: 

•  The  JFACC  must  be  able  to  determine  the  impact  and  effects  of  past,  current  and 
projected  actions  at  any  given  point  in  time 

•  The  complexity  of  the  problems  that  the  JFACC  faces  cannot  be  easily  achieved  with  a 
single  visualization  or  presentation 

•  The  JFACC  requires  actionable  information  -  the  approach  herein  was  to  elevate 
previous  information  related  an  actionable  level 

Visualization  concepts  from  CEP  are  shown  in  Figures  2  and  3.  The  command-centric  (JFACC 
level)  visualization  shown  in  Figure  2  provides  the  high-level  “at  a  glance”  view  of  air 
operations.  The  Projected  Plan  Activity  visualization  shown  in  Figure  3  provides  the  actionable 
information  necessary  to  for  a  48  hour  and  beyond  view  on  operations. 


Figure  2  CEP  Command-Centric  Visualization 
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Figure  3  CEP  Projected  Plan  Activity  Visualization 


Prototypes  were  developed  incrementally  as  the  requirements  analysis  continued.  These 
incremental  CEP  prototypes  were  then  used  to  stimulate  inputs  from  representative  warfighters 
and  SMEs  from  the  AOC  Strategy  Planning  community  during  sidebar  elicitations  at  Checkmate 
2006  and  Global  Cyberspace  Innovation  Center  (GCIC)  sponsored  Warfighter  Assessment 
Workshops.  The  concepts  were  well-received  by  the  warfighter  communities  and  were  further 
steered  by  Lt.  Gen.  Charles  R.  Heflebower  (Ret.),  one  of  the  senior  mentors. 


3.3  GLOBAL  EFFECTS  MANAGEMENT  SYNCHRONIZATION 

The  Joint  Information  Operations  Warfare  Capability  (JIOWC)  was  interested  in  exploring 
visualization  concepts  for  an  effects  management  concept  termed  GEM-S.  Initial  concepts  were 
drawn  from  the  CEP  and  presented  to  the  JIOWC  in  February  2006  as  a  concept  supporting  the 
GEM-S.  Subsequent  design  iterations  for  the  GEM-S  prototype  were  based  on  CEP  and  evolved 
over  several  months  based  on  close  interaction  with  operational  users  and  stakeholders  from  the 
JIOWC.  The  following  paragraphs  describe  the  features  GEM-S  is  intended  to  support.  The  spirit 
of  these  design  features  carry  through  most  aspects  of  SPVT  and  thus  are  described  in  detail 
through  this  section. 

GEM-S  is  a  planning,  assessment  and  campaign  monitoring  capability  designed  to  operate  as  a 
thin  client  over  a  service  oriented  architecture.  It  provides  a  collaborative  environment  for  users 
operating  at  multiple  levels  of  command  and  across  multiple  communities  of  interest.  GEM-S 
provides  support  for  kinetic  and  non-kinetic  operations,  and  includes  unique  capabilities  which 
enable  users  to  create  and  share  user-defined  displays,  develop  and  modify  plans  from  geospatial 
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and  temporal  perspectives,  and  create  and  assess  lines  of  effect.  Innovative  views  also  provide 
tailored  campaign  situational  awareness  for  planners,  analysts  and  commanders.  The  primary 
visualization  and  information  components  unique  to  GEM-S  include  Operations,  Activities  & 
Actions  (OAA),  Lines  of  Effects  (LOE),  10  Assessment  and  Information  Ticker  views  and  are 
best  described  in  the  following  operational  context. 

Once  an  operation  is  underway,  operations  assessors  begin  performing  assessments  at  all  levels 
of  the  campaign.  By  opening  each  plan  element  and  Measure  of  Effectiveness  (MOE),  planners 
and  assessment  analysts  document  the  current  plan  element  state,  assessment  trend  and  assessed 
effect  status.  Selecting  an  assessment  status  presents  the  user  with  two  measurements;  Magnitude 
Score  and  Direction  Score.  The  effect  Magnitude  refers  to  the  “mass”  of  the  effect  achieved 
when  compared  to  the  desired  amount.  The  effect  Direction  refers  to  the  positive  or  negative 
achievement  of  the  desired  effect. 

Campaign  situational  awareness  is  afforded  through  several  innovative  views.  The  OAA  view 
displays  an  array  of  information  about  plan  contributions  and  dependencies  as  well  as  current 
status  and  trend  information  (see  Figure  4).  Each  of  the  strategic  prioritized  effects  is  displayed 
at  the  top  of  the  screen.  The  colored  circles  to  the  left  indicate  the  current  state  of  each  plan 
element.  A  green  circle  indicates  operations  supporting  this  effect  are  currently  being  executed, 
yellow  indicates  operations  are  planned  but  not  yet  in  progress,  and  red  indicates  the  supporting 
operations  have  yet  to  be  planned.  The  colored  triangles  next  to  the  circles  indicate  the  current 
status  and  trend  of  the  plan  element.  An  upward  pointing  triangle  indicates  an  improvement 
trend,  a  downward  a  worsening  trend  and  to  the  side  indicates  no  change.  The  color  within  the 
triangle  indicates  the  current  assessment  of  that  effect,  with  gradients  of  red,  yellow  and  green 
indicating  various  degrees  of  positive  or  negative  effect.  This  same  methodology  is  repeated  for 
the  other  levels  of  command.  Note  the  triangles  in  the  center  matrix  also  indicate  which 
Prioritized  Effects  List  (PEL)  effects  they  are  supporting. 
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Figure  4  GEM-S  Operations,  Activities  and  Actions  (OAA)  view 

The  LOE  view  (see  Figure  5)  allows  the  planners  to  establish  supporting  relationships  that  show 
how  each  lower  level  effect,  objective  or  task  contributes  to  the  desired  effects  at  the  higher 
level.  The  LOE  view  enables  one  to  display  these  often  complex  contributions  and  dependencies. 
The  same  four  levels  of  command  within  the  Synchronization  View  are  represented  here.  Once 
these  relationships  have  been  established  joint  planners  may  apply  weighting  factors  to 
determine  the  contribution  of  each  supporting  effect.  This  weighting  will  play  a  significant  role 
during  the  ops  assessment  process  by  dictating  how  much  each  individual  lower  level  assessment 
is  able  to  influence  the  success  or  failure  of  higher-level  effects. 

Upon  selecting  the  “Lines  of  Effect”  check  box,  these  relationships  are  displayed,  linking  each 
lower  level  effect  or  objective  to  the  high  level  effect  to  which  it  contributes.  Note  also  that  the 
varied  line  thickness  between  the  elements  represents  the  weighting  established  earlier  in  the 
planning  process.  A  user  who  wishes  to  view  a  single  line  of  effect  can  simply  go  to  the  fly-over 
view  at  the  top  left  and  mouse  over  each  plan  level  to  select  the  specific  effect  of  interest.  Once 
the  desired  element  is  selected,  only  the  plan  elements  to  which  that  effect  depends  or  contributes 
are  displayed.  This  function  may  be  performed  at  any  plan  level  of  the  campaign  hierarchy.  Real 
time  information  updates  are  capable  through  the  Information  Ticker  (scrolling  text)  at  the 
bottom,  center  of  the  view. 
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Figure  5  GEM-S  Lines  of  Effect  (LOE)  view 

The  view  which  completes  GEM-S  is  the  PEL  Assessment  (see  Figure  6).  This  view  is  intended 
to  show  a  top  level  status  of  the  entire  campaign  by  displaying  the  current  assessed  status  of 
every  desired  effect  in  the  campaign. . .  at  each  level  of  command.  The  PEL  Assessment 
approach  provides  a  means  for  commanders  to  obtain  immediate  high-level  awareness  of  the 
success  level  for  each  desired  effect.  At  each  selected  campaign  level,  diamond  shapes  represent 
each  effect  present.  Each  effect  consists  of  two  values:  Effect  Magnitude  and  Effect  Direction. 
The  PEL  Assessment  view  captures  both  values  on  orthogonal  axes. 

The  vertical  axis  represents  the  magnitude  score  while  the  horizontal  axis  represents  the  direction 
score.  Note  the  exponential  values  at  the  top  for  the  “viral”  magnitude  score  previously 
discussed.  Each  of  the  effects  is  plotted  on  this  view  using  the  scores  found  on  the  status  tab  of 
each  effect  measure.  Commanders  and  other  decision  makers  may  quickly  see  which  effects  are 
on  track  and  which  require  further  attention. 
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Figure  6  GEM-S  PEL  Assessment  view 


Appendix  A  Volume  II  contains  detailed  theoretical  and  operational  descriptions  of  the  GEM-S  10 
Assessment  view  (developed  by  SAIC  under  subcontract  to  SRA). 


3.4  JAOP  AOD  STATUS  TOOL  (JAST) 

JAST  was  the  product  of  a  need  to  complete  a  key  feedback  path  from  Combat  Operations 
Division  to  the  Strategy  Division.  The  Planning  and  Execution  Status  Bar,  as  described  in  the 
IWPC  CPT  Software  User’s  Manual  (SUM)  supports  the  planning  process  by  providing  useful 
combat  planning  and  execution  status  data  correlated  to  a  published  Joint  Air  Operations  Plans 
(JAOP)  and  the  daily  Air  Operations  Directives  (AOD).  The  SD  produces  the  AOD  which  is 
used  to  develop  the  daily  ATO.  Often,  information  regarding  whether  a  mission  on  the  current 
ATO  is  1)  scheduled,  and  2)  executed,  is  unknown  through  SD’s  next  iteration  of  the  AOD.  The 
missing  information  requires  the  SD  to  re-plan  a  mission  or  missions  whose  execution  status  is 
unknown  in  order  to  ensure  the  tactical  goal  (effect)  is  achieved.  The  opportunity  to  complete 
this  feedback  path  was  realized  with  the  inception  of  TBONE. 

The  design  of  IWPC  version  4.2b  called  for  TBONE  to  be  (I)  a  receiver  of  IWPC  strategy 
planning  products  (e.g.  JAOP  and  AOD),  and  (2)  a  source  of  plan  status  data  to 
include  publishing  the  plan  and  tracking  status  for  plan  elements  as  they  move 
through  targeting,  allocation,  execution  and  assessment.  JAST  was  the  interface  to  bring  the 
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TBONE  combat  operations  data  back  into  the  strategy  planning  world  of  IWPC.  JASP  was  the 
interface  to  bring  the  TBONE  targeting,  allocation,  and  execution  data  back  into  the  strategy 
planning  world  of  IWPC.  The  IWPC  CPT  requirements  in  Table  1  are  shown  with  the  JAST 
requirements  analysis. 


Table  1.  JAST  Planning  and  Execution  Status  Requirements 


Requirement  ID 

Description 

CPT-PE-0001 

The  application  shall  provide  the  user  the  capability  to  track  the 
status  of  Air  Tasking  Orders  (ATO)  planned  and  executed  for  each 
Air  Operations  Directive  (AOD)  or  Joint  Air  Operations  Plan 
(JAOP). 

CPT-PE-0002 

The  application  shall  provide  the  user  with  the  capability  to  load 
planning  and  execution  status  associated  with  an  AOD. 

CPT-PE-0003 

The  application  shall  provide  the  user  with  the  capability  to  request 
updates  to  planning  and  execution  assessment  data 

CPT-PE-0004 

The  application  shall  provide  the  user  with  the  capability  to  view 
planning  and  execution  status  data  for  each  effect 

CPT-PE-0005 

The  application  shall  automatically  provide  the  user  with  the  ability 
of  keeping  track  of  what  planning  and  execution  status  data  has 
been  viewed  and  unviewed  for  each  effect 

CPT-PE-0006 

The  application  shall  provide  the  user  with  the  capability  of  copying 
planning  and  execution  status  data 

CPT-PE-0007 

The  application  shall  provide  the  user  with  the  capability  to  clear 
out  the  tracked  unviewed  planning  and  execution  status  for  each  and 
all  effects. 

The  IWPC  Execution  Status  and  Assessment  data  interfaces  leverage  the  TBONE  Services  and 
data  model.  The  services  and  supporting  Java  2  Platform  Enterprise  Edition  (J2EE)  components 
for  this  component  of  the  IWPC  interface  to  TBONE  is  provided  through  JAST. 

JAST  provides  the  following  capabilities  back  to  IWPC: 

•  JAOP/AOD  Element  Timing 

•  JAOP/AOD  Associated  Target  Status 

•  JAOP/AOD  Decision  Point  Status 

•  JAOP/AOD  Mission  Status 

These  capabilities  are  shown  in  Figure  7,  where  each  tabbed  section  contained  detailed 
information  on  Timing,  Targets,  Decision  Points  and  Missions.  The  data  handled  by  JAST 
provided  interesting  user  interaction  design,  in  that  JAST  was  intended  to  provide  “updated” 
information.  A  user  interface,  itself,  is  unaware  whether  a  user  has  processed  new  information. 
Therefore,  users  were  required  to  acknowledge  (interact  with  JAST)  when  new  information  was 
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presented.  One  example  is  shown  at  the  bottom  of  Figure  7,  where  light  blue  baekgrounds  on 
ieons  represents  an  information  update  is  available. 
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Figure  7  JAST  implementation  in  the  IWPC  CPT  Module 


JAST  is  designed  as  a  Service  Oriented  Architecture  (SOA).  JAST  complies  with  the  J2EE  1.4 
specification  and  thus  is  scalable  and  secure.  Termination  of  the  TBONE  program,  however,  just 
prior  to  IWPC  deployment  meant  JAST  had  to  be  disabled  within  IWPC  4.2,  i.e.  no  data  feed 
existed  to  populate  JAST.  To  support  JAST  integration  with  IWPC,  the  following  items  were 
delivered  initially  in  October  of  2005  with  software  updates  (based  on  changes  to  the  IWPC 
Software  Developer  Toolkit,  SDK)  as  required  through  December  2006. 

•  JAST  IWPC  Client  Software 

•  JAST  Software  and  Subsequent  Updates 

•  eSync/Collaborative  Planning  Tool  (CPT)  Software  Users  Manual  (JAST  enhanced) 

•  JAST  Code  Interface  Control  Document  (ICD)  Update 

Appendix  A  and  B  contain  the  CPT  SUM  (Sections  5.3.8  -  5.3.10.8)  and  eSync  SUM 
(Sections  5. 3. 3. 8  -  5.3.3.10.10),  respectively.  Each  SUM  was  modified  to  account  for  inclusion 
of  JAST-related  information  within  IWPC  (Note:  these  SUMs  were  provided  to  the  IWPC  prime 
contractor  as  examples  of  where  JAST  reference  material  best  fit,  however,  additional  technical 
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editing  was  conducted  by  the  prime  and  thus  these  documents  do  not  represent  the  SUMs 
delivered  with  IWPC  v  4.2e).  The  SUMs  provide  an  excellent  detailed,  functional  overview  of 
JAST  capabilities  within  the  respective  IWPC  capability  module. 


3.5  COURSE  OF  ACTION  (COA)  SKETCH 

Course  of  Action  (COA)  Sketch  is  a  concept  that  was  focused  on  the  concept  of  “visually” 
developing  the  plan  in  the  AOC  Strategy  Division  context.  The  visual  plan  development  concept 
evolved  from  a  workshop  sponsored  under  the  SPVT  contract  to  explore  human-centered  work 
aids  for  Strategy  Planners  conducting  COA  development.  Major  Stewart  Greathouse  (USAF  ret) 
provided  the  structure  for  core  elements.  Visual  plan  development  work  methods  previously 
included  strategy  planners  drawing  the  plan  on  a  whiteboard  or  map  and  subsequently  moving 
those  thoughts  and  artifacts  to  other  existing  planning  tools  which  supported  only  a  structured, 
hierarchical  plan. 

COA  Sketch  allows  users  to  create  planning  elements  within  both  a  geographic  and  temporal 
context  (see  Figure  8).  Further,  strategy  planners  are  able  to  visually  initiate  the  planning  process 
and  drive  a  more  collaborative  and  cohesive  interchange,  enabling  understanding  of  horizontal 
and  vertical  nesting  of  objectives,  priority  effects,  and  operations.  COA  Sketch  is  a  multi-user 
tool  with  attribute  level  locking  and  near  real-time  data  updates  which  enables  several  users  to 
work  on  a  single  plan  simultaneously,  and  further,  observe  how  others  are  contributing  to  plan 
development. 


Figure  8  COA  Sketch  Workspace,  Sketch  &  Synchronization  views 


COA  Sketch  emphasizes  moving  unstructured  data  from  the  selected  human-to-human 
collaboration  environment  into  structured  information  sets  realized  within  Community  of  Interest 
(COI)  specific  supporting  tools.  In  this  case,  “tools  that  collaborate”  such  as  COA  Sketch  share 
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unstructured  data  captured  from  the  human-to-human  collaboration  environment  and  provide 
structure,  augmentation  and  presentation  of  the  data  such  that  users  can  generate  a  shared  or 
common  understanding  from  multiple  perspectives  on  the  data. 

Findings  f  rom  interviews  with  AOC  SMEs  indicated  th  at  the  Subject  Matter  Analysis  and 
Research  Toolkit  (SMART)  tool  showed  great  promise  for  the  discovery,  organization  and 
sharing  of  information  for  personnel  conducting  Intelligence  Preparation  of  the  Operational 
Environment  and  other  Mission  Analysis  activities.  SMART  also  provides  search  and  tagging 
capabilities  for  structuring  data  from  unstructured  data  elements.  Mac  hine-to-Machine  (M2M) 
transfer  of  the  tagged  artifacts  between  the  SMART  and  COA  Sketch  tools  completes  one  aspect 
of  tool  collaboration.  Further,  SME  feedback  suggested  that  the  COA  Sketch  tool’s  ability  to 
capture  geospatial  artifacts  previously  only  found  in  whiteboard  sketches  and  translated  into 
PowerPoint  slides  would  benefit  all  SD  planners. 

Current  human-to-human  collaboration  tools  generate  unstructured  data  while  community  of 
interest  (COI)  specific  tools  are  usually  designed  using  object-oriented  techniques  focused  on  a 
particular  COI.  A  COI  focus  helps  ensure  the  data  captured  is  well  structured.  To  begin,  one 
must  establish  a  taxonomy  of  COI-defined  entities  and  data  formats  for  the  exchange  of 
information  between  candidate  applications  such  as  SMART  and  COA  Sketch.  Current  industry 
and  DoD  trends  include  the  use  of  web  services  for  data  exposure  and  interchange,  and  therefore 
loosely  coupled  integration  through  web  service  interfaces.  Proof-of-concepts  were  performed, 
allowing  the  interactive  capabilities  of  SMART  and  COA  Sketch  to  facilitate  production  of  end 
product  focused  objects  and  attributes  during  the  collaboration.  The  goal  of  these  extensions  was 
to  provide  the  end  user  the  ability  to  associate  unstructured  data  elements  to  COA  Sketch 
Mission  Analysis  entities  using  SMART’S  tagging  capability.  Figure  9  provides  a  high-level 
graphical  use  case  demonstrating  this  type  of  interoperability.  More  detailed  use  cases  are 
provided  in  Appendix  B  COA  Sketch  Use  Cases. 
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High  Level  Use  Case 


1)  krtal  Analyst  entnrs  Mission  Analysis  (MA)  quastion  or  koywords  into  SMART 


Operator  Searches  Ibranswerto  intann^n  need 
2a>  SMART  analy2»s  requast  (KayMotd  orStruchiiad^ 

2b^  SMART  suppoils  options  to  dartiy  question  and  searcti  query 
2c)  SMART  performs  saardies  display  results  to  user 

SjfstBmsugge^s  aimnliBregs/c/7  terms,  end  sends  bad(  aaetrh  ' 

roaufts  mckiding  amffarf^s,  suggogtad SKEs,  simMar  3)  User  collects  interesting  notes  within  a  research  notebook 
feaeaah,  ihiTEUNK  and  M3  eeeioh  fssu/Zs 

4)  User  uses  SMART  WfA  Tags  to  identify  MA  artifacts 
*  in  unstructured  documents 

5)  SMART  adds  traceability  metadata  to  tagged  artifact  and  stores  in  knowledge  folder 

6)  User  selects  COA  Sketch  instance  to  which  to  publish 

6)  SMART  establishes  connection  with  COA  Sketch  endpoint  and  displays  Organizations  perfoiming  MA 

^  7)  User  selects  Organization  to 
whom  to  publish  collected  MA 

8)  SMART  sets  select  Org  as  publishing  destination  artifacts 


9)  Selects  artifacts  for  publishing  from  research  notebook 
on  an  individual  basis  or  selects  to  publish  all  aulifacts 

10)  SMART  publishes  artifsK^ts  and  marks  them  as  published 


1 1)  Traceable  Structured  MA  data  is  received  by  all  SMART  and 
COA  Sketch  Users  in  the  desired  organization 

- COA  Sketch  Uher 


Figure  9  High  level  use  case  for  unstructured  to  structured  data  processing 


COA  Sketch  provides  the  following  benefits: 

•  Machine  to  machine  exchange  of  data  &  graphics  to  enable  collaborative  planning  by  all 
AOC  teams 

•  Planners  support  in  developing  COAs  with  a  series  of  visualizations  and  workspace  tools 

•  The  ability  to  develop  plans  using  true  geographic  information  (versus  PowerPoint) 

•  A  graphic  &  collaborative  framework  in  which  to  develop  &  coordinate  the  JAOP 

•  Decentralized  execution  while  informing  senior  decision  makers 

•  Increased  awareness  of  operations  that  transcends  multiple  AORs  and  enables  timely  & 
informed  decision  making 

COA  Sketch  is  a  thin-client  technology  comprised  of  several  modules  or  views  designed  to 
provide  decision  support  to  the  Strategy  Division  when  considering  combat  options.  The  main 
views  include  Map  Sketch,  Synchronization,  Mission  Analysis,  and  Plan  Player.  Each  view 
provides  a  specific  perspective  on  plan  data.  COA  Sketch  provides  the  user  the  flexibility  to 
choose  appropriate  views  and  spatially  arrange  them  to  best  support  work. 

Table  2  summarizes  implemented  and  pending  COA  Sketch’s  main  features. 
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Table  2.  COA  Sketch  Main  Features 


High-Level  Feature 

Function 

Administrative  Manage 

user  accounts  and  privileges 

Collaborative  Environment 

Attribute  level  locking  on  data  fields  enables 
multiple  persons  to  work  at  the  same  time  and  to 
view  plan  updates  in  near  real  time 

Mission  Analysis 

Develop  mission  analysis  artifacts 

Plan  COA  (Synchronization) 

Create  and  modify  plan  elements,  CO  As,  and 
associated  objects 

Plan  Player 

Display  temporal  execution  of  plan  elements 
across  Synchronization  and  Sketch  views 

Situational  Reference  Point  (not  fully 
implemented) 

Save  a  workspace  view/layout  for  reference  or 
use  at  a  later  time 

Sketch  Create 

and  associate  plan  objects  geographically 
to  Synchronization  View  plan  elements 

Work  Flow  (not  fully  implemented) 

Complete  work  method  templates  for  specified 
strategy  roles 

Most  noteworthy  for  COA  Sketch,  and  an  indicator  of  SPVT’s  ability  to  address  warfighter 
needs,  was  the  program’s  transition  to  the  USSTRATCOM  Integrated  Strategic  Planning  & 
Analysis  Network  (ISP AN)  program  of  record  in  September  2009.  COA  Sketch  was  also 
integrated  into  the  lOPC-X  database  ontology  which  allows  data  to  be  exchanged  freely  with 
other  lOPC-X  Capability  Modules  (see  Section  3.7  for  a  description  of  lOPC-X).  Sections  3.5.1 
through  3.5.4  describe  the  process  through  which  COA  Sketch  evolved  and  the  high  level 
capabilities. 

3.5.1  COA  SKETCH  ASSESSMENT  EVENTS 

The  initial  COA  Sketch  design  was  derived  from  user  information  and  decision  making 
requirements  described  in  Section  3.1.  COA  Sketch  was  subsequently  refined  through  feedback 
from  a  series  of  interviews  and  evaluations  conducted  with  AOC  SD  SMEs.  While  many 
important  contributions  to  COA  Sketch  design  and  development  were  obtained  through 
numerous  opportunistic  interview  and  evaluation  sessions  with  one  or  two  SMEs,  two 
particularly  significant  events  provided  substantial  advances  in  concept  and  capability. 

The  first  significant  evaluation  event  served  as  an  opportunity  to  expose  warfighters  to  early 
COA  Sketch  concepts.  The  event,  termed  Warfighter  Assessment  of  Innovative  Technologies 
and  Concepts  (WAITnC),  was  conducted  17-21  September,  2007  at  the  Ryan  Center,  Langley 
AFB,  VA.  More  than  twenty  warfighters  provided  representation  from  several  operational 
squadrons  with  experience  across  the  Strategy  Plans  Team  and  Operational  Assessment  Team. 
Technologies  from  several  USAF  sponsored  programs  provided  the  technology  base  against 
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which  the  warfighters  eould  generate  assessments.  Senior  JFACC  mentor  Lt  Gen  (USAF  ret)  Joe 
Hurd  provided  a  commander’s  perspective  on  the  event. 

SPVT  sponsored  two  teehnologies,  COA  Sketeh  and  Strategy  Air  Alloeation  Planner  (SAAP), 
for  the  WAITnC  event.  SPVT  objectives  for  the  event  ineluded:  1)  evaluate  the  teehnologies 
throughout  the  JAEP  proeess  to  identify  gaps  in  eapability;  2)  verify  aeeuraey  of  respective  use 
cases  against  implementation;  3)  identify  mismatehes  between  support  for  user  information  and 
decision  making  requirements  as  implemented  in  eaeh  teehnology;  4)  identify  performanee 
improvement/degradations  with  respeet  to  time  on  task;  and  5)  establish  eriteria  for  produet 
quality.  An  objeetive  speeifie  to  COA  Sketch  was  vetting  the  work  flow  management  coneept 
and  to  SAAP  was  determining  overall  technology  benefit  to  the  warfighter. 

The  WAITnC  event  provided  an  opportunity  to  mature  the  COA  Sketch  and  SAAP  conceptual 
designs.  Development  at  this  early  eonceptual  design  phase  consisted  mainly  of  representing 
capabilities  through  interaetive  user  interfaces  with  minimal  effort  given  to  generate,  store  and 
otherwise  manipulate  data.  This  approaeh  maximized  support  to  warfighter  information  and 
decision  aiding  requirements  while  minimizing  software  development  effort,  thus  helping  ensure 
future  program  effort  was  foeused  on  developing  the  right  eapabilities.  Further,  these  interaetive 
user  interfaces  provided  SMEs  a  richer  environment  in  which  to  evaluate  and  evolve  concepts.  A 
SAAP  interactive  user  interface  is  shown  in  Figure  10.  Warfighters  were  able  to  seleet  menu 
options,  manipulate  controls,  and  adjust  the  values,  as  if  interacting  with  a  “live”  system. 


Figure  10  Strategy  Air  Allocation  Planner  concept 


Warfighter  feedback  during  WAITnC  verified  the  appropriateness  and  aeeuraey  of  the  approach 
and  method.  Speeifie  functionality  such  as  Map  Sketch  integration  with  Synehronization  was 
well-reeeived  and  prioritized  higher  relative  to  SAAP  functionality.  This  may  have  been  due  in 
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part  to  the  lack  of  Combat  Plans  Division  representation  at  this  event  and  therefore  a  lack  of 
immediate  proponents  (i.e.  users/beneficiaries  of  the  technology)  for  the  SAAP  technology. 

The  second  significant  evaluation  event  served  as  an  opportunity  to  exercise  COA  Sketch  and  its 
inherent  collaboration  features  within  a  distributed  AOC  Strategy  Planning  scenario.  The 
Collaboration  event  was  a  culminating  activity  for  SPVT.  COA  Sketch  had  matured  significantly 
over  the  previous  two  years  and  relative  to  that  presented  at  the  WAITnC.  The  COA  Sketch 
technology  was  much  more  complete  from  user  interface  through  data  storage,  although  software 
development  was  not  production  ready  or  capable.  For  the  Collaboration  event,  however,  COA 
Sketch  had  emerged  as  a  thin  client  technology  with  user  interfaces  developed  from  state  of  the 
art  software  (Adobe  Flash/Flex).  The  advanced  interfaces  provided  a  powerful  medium  through 
which  COA  Sketch  concepts  were  communicated. 

The  collaboration  event  was  conducted  14-18  September,  2009  across  distributed  sites  with  eight 
experienced  strategy  planners,  operational  assessment  personnel  and  intelligence  analysts  (see 
Section  3.8  for  a  more  detailed  description  of  the  Collaboration  in  the  AOC  Context  assessment 
event).  Planners  aggregate  disparate  unstructured  sets  of  data  back  into  a  PowerPoint 
presentation  and  the  Information  Warfare  Planning  Capability  (IWPC)  planning  tool  to  re¬ 
associate  context  and  meaning  from  the  COA  development  process.  While  IWPC  acts  as  a 
repository  for  the  aggregation  of  much  of  this  data  into  a  structured  data  format,  the  tool  is  not 
commonly  used  interactively  during  the  development  of  a  COA.  The  fidelity  of  the  IWPC  data 
model  is  also  lacking,  textual  descriptions  are  commonly  used  vs.  discrete  elements  and 
attributes  throughout  the  tool,  forcing  human  cognition  of  meaning  vs.  system  processing  into 
human  perceivable  contextual  relationship  visualizations.  It  is  this  disconnect  between  the  human 
work  process  and  available  tools  which  is  addressed  with  the  integration  of  COA  Sketch  and 
other  work-centered  tools  that  collaborate  into  the  collaboration  environment. 

COA  Sketch  was  particularly  well-suited  to  participate  as  a  technology  in  the  collaboration  event 
because  the  COA  Sketch  design  was  enhanced  to  enable  multiple,  distributed  users  to  work 
simultaneously  on  a  plan.  Collaborating  tools  such  as  COA  Sketch  allow  computer  systems  to 
provide  human  automated  assistance  in  the  knowledge  gathering  process.  This  assistance  can 
occur  while  enhancing  the  knowledge  with  automated  traceability  to  sources  for  human 
confidence  determination,  and  thereby,  support  human  trust  in  the  automation.  Visual  thinking 
also  is  more  readily  supported  since  associated  metadata  on  the  knowledge  set  was  machine 
correlated  to  multiple  information  portrayal  options  provided  by  the  systems. 

The  COA  Sketch  technology  was  well-received  at  the  Collaboration  event.  At  the  time  of  the 
event,  representatives  from  the  ISP  AN  program  were  actively  engaged  in  identifying 
technologies  which  could  quickly  benefit  the  strategy  planning  capability  within  ISPAN.  One 
projected  way  ahead  included  applying  COA  Sketch  user  interfaces,  in  whole  or  part,  as  an 
alternate  view  onto  ISPAN  data.  More  details  on  the  collaboration  event  can  be  found  in 
Appendix  E. 

3.5.2  COA  SKETCH  USE  CASES 

SRA’s  Human-Centered  Systems  Engineering  Process  was  used  to  generate  use  cases  which 
formed  the  basis  for  the  COA  Sketch  functional  design.  Initial  use  cases  were  based  largely  on 


19 


the  user  requirements  analysis  eondueted  early  in  the  SPVT  program.  The  use  cases  were 
subsequently  refined  during  design  review  meetings  with  an  integrated  development  team 
including  software  and  human  factors  engineers.  Operational  expertise  was  added  through  inputs 
from  a  combination  of  in-house  and  external  SMEs.  Mr.  Clarence  “Clay”  Olschner  contributed 
substantially  to  use  case  refinement  and  verification.  COA  Sketch’s  high-level  use  case  is  shown 
in  Figure  1 1 . 


fs 


1) Ugfe  witer  URL  to  COA  Siceteh  in  wb  bnwwr  to  launch  tha  applicatwn 


2)  COCOM  or  JTF  Staff  Opan  aatisfrig  or  create  anew  Operation _ 

2a)  COCOM  cr  «JTF  Staff  ontar  organEaticns  iiwdvad  &  POCa 

2b)  Each  organization  antorc  Guidance  (method,  purpose  &  end  stable) 

2c)  COCOM  or  JTF  Staff  add  a  COA  &  providB  Timing  (Ci  D  day  ate.)  and  Phasir^ 


Commandar  (s) 


3)  Colaboradve  analysis  of  ordorsi,  plarmaig  products^  end  JFC  mission  and  intent 

3a)  kJentilV  knosm  facts,  RevieiM/Dawalap  BssiMnptians,  Defarmiie  limitations 
3b)  Reviaw/Anelyze  IPB  and  enemy  &  friendly  COGs 

3c)  Detennine  Tasks  (specified,  impliad,  essential) 

3d)  Determsie  initial  risk  assessment 


Operaflbff  CoflaboraCors 
(JTF^  campanoni  eamrandlg,^) 


^4)  Develop  altemat^  COAs 

4a)  Develcp  layered  sketches  for  each  COA 
4b)  UwBkjp  operational  &  tactical  oblectfvas,  et& 

4c)  Determfrie  phaaiig,  sequencing,  priority,  and  risk 
4it)Vertiy  vallcity 


S)  Brief  Commandeiis)  and  lecaiva  approval 


6)  Publish  Operaltan  URL  to  down  siraam  dh/lslans 


Operatkm  CaHaboiatoFS 
(campoaenCcoirmands.,.} 


Figure  11  COA  Sketch  High-Level  Use  Case 


The  COA  Sketch  SUM  contains  a  brief  description  of  the  software,  installation  instructions  and  a 
reference  guide.  The  COA  Sketch  SUM  is  provided  in  Appendix  C. 

3.5.3  COA  SKETCH  CONOPS 


A  brief  scenario  best  provides  an  overview  of  COA  Sketch  features.  When  an  operation  is  first 
created,  planners  identify  initial  timing,  phasing  and  tasked  mission.  These  elements  are  further 
refined  later  in  the  planning  and  execution  process.  As  the  planning  staff  continues  with  Mission 
Analysis  they  identify  planning  assumptions,  limitations,  centers  of  gravity  as  well  as  specified 
and  implied  tasks.  To  make  this  effort  a  bit  easier  and  more  accurate,  COA  Sketch  provides  some 
helpful  features.  COA  Sketch  includes  a  workflow  manager  which  steps  users  through  common 
processes,  such  as  Mission  Analysis.  Another  helpful  feature  provides  planners  with  a  means  to 
add  items  to  the  Mission  Analysis  portion  of  the  campaign  directly  from  the  planning  orders 
from  which  they  originated  via  web  services  and  a  related  AFRL  technology  known  as  SMART. 
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Once  Mission  Analysis  is  complete,  planners  begin  to  develop  courses  of  action  to  satisfy 
National  objectives.  COA  Sketch  supports  four  planning  levels,  enabling  vertical  collaboration 
of  the  entire  planning  and  execution  effort.  As  many  COA  candidates  as  desired  may  be  created, 
with  the  selected  COA  being  designated  as  the  “Plan”  for  each  level  of  command.  To  satisfy 
National  objectives,  the  Joint  planning  staff  develops  the  Commander’s  prioritized  effects  list,  or 
PEL,  for  a  campaign. 

PEL  effects  speak  to  each  of  the  national  objectives  and  can  range  from  defeating  fielded  forces, 
to  isolating  leadership  to  winning  the  hearts  and  minds  of  the  people.  These  high  level  effects  are 
also  assigned  Measures  of  Effectiveness  which  are  used  later  to  assess  campaign  success.  Other 
details  such  as  a  description  and  planning  status  may  also  be  added.  Using  the  Map  Sketch 
feature  (see  Figure  12),  planners  may  draw  map  shapes  and  annotations  and  assign  them  to 
specific  plan  elements.  These  areas  can  be  linked  to  any  portions  of  the  plan,  from  Assumptions 
and  Limitations,  to  desired  effects,  objectives  and  tasks.  For  example,  an  influence  operations 
area,  a  named  area  of  interest  or  a  no  fly  zone  may  be  associated  with  any  plan  element.  Users 
may  also  create  new  plan  elements  directly  from  the  Map  Sketch  view.  The  user  selects  the 
desired  map  layer,  draws  and  positions  the  shape,  and  selects  the  type  of  plan  element.  The  new 
plan  element  is  immediately  added  to  the  plan. 


Figure  12  COA  Sketch  Plan  and  Map  Sketch  view 

During  this  time,  participating  components  begin  to  develop  courses  of  action  to  achieve  the 
Joint  Commander’s  desired  effects.  COA  Sketch  supports  COA  analysis  and  comparison  by 
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offering  a  collection  of  intelligent  forms,  tables  and  matrices  to  guide  the  planning  staff  through 
the  process.  Once  a  COA  has  been  selected  the  Joint  Commander’s  PEL  effects  are  decomposed 
into  operational  effects,  objectives  and  tasks. 

So  now  plans  have  been  developed  at  various  command  levels,  assigned  effectiveness  and 
performance  measures,  and  developed  lines  of  effect  by  establishing  relationships  between  the 
higher  and  lower  level  effects  and  objectives.  Next,  the  planner  integrates  and  synchronizes  the 
various  desired  effects  and  activities  and  begins  to  establish  initial  strategic  and  operational 
timing  and  phase  alignment.  To  modify  plan  timing,  the  planner  simply  uses  the  mouse  to  adjust 
the  element  start  time  and  duration.  Note  that  the  plan  element  MOEs  also  has  timing  attributes 
to  identify  optimal  measurement  opportunities. 

To  visualize  how  the  plan  will  “play  out’’  over  the  duration  of  the  campaign,  COA  Sketch  offers 
a  Plan  Player.  This  feature  provides  planners  a  capability  to  visualize,  brief  or  rehearse  planned 
events  across  the  operational  timeline.  The  Map  Sketch  view  is  included  during  playback  to  add 
fidelity  and  will  display  the  associated  shapes  and  annotations  as  they  occur  in  the  timeline. 

COA  Sketch  also  provides  several  multi-user  collaboration  features.  First,  users  can  build  and 
edit  plans  simultaneously  within  COA  Sketch  with  planning  efforts  from  both  Joint  and 
Component  levels  integrated.  Second,  plan  integrity  is  maintained  by  assigning  role-based 
permissions  and  locking  individual  plan  elements  during  modification.  Thus,  users  can  work  on  a 
plan  simultaneously  at  the  data  attribute  level.  Finally,  COA  Sketch  enables  real-time  update 
notification.  That  is,  users  are  notified  when  plan  updates  occur  and  can  see  the  updates  within 
COA  Sketch. 


3.5.4  COA  SKETCH  ARCHITECTURE 

The  COA  Sketch  system  architecture  is  shown  in  Figure  13.  A  more  detailed  description  of  COA 
Sketch  data  transactions  can  be  found  in  Section  3.7  Information  Operations  Planning  Capability 
-  Experiment  (lOPC-X).  Refinements  to  this  architecture  can  be  found  in  the  final  report  for 
another  71 1  HPW  Human  Engineering  Directorate  program.  Commander’s  Predictive 
Environment  (CPE).  lOPC-X  was  a  risk  reduction  experiment  developed  under  the  HE  in  the 
AOC  -  SPVT  program  to  serve  as  a  persistent  data  store  capability  for  COA  Sketch.  Updates  to 
the  lOPC-X  data  store  are  broadcast  to  JMS  listeners.  COA  Sketch  maintains  a  listener  for 
lOPC-X  update  events  and  repeats  them  to  thin  clients  attached  to  the  Blaze  DS  data  source. 
Appendix  B  Volume  Ilcontains  the  lOPC-X  SDK  which  addresses  the  COA  Sketch  data  model 
in  more  detail. 
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Figure  13  COA  Sketch  /  lOPC-X  System  Architecture 


3.6  TENEO 

The  ESC  ISRSG/KIS  and  JIOC  teams  wanted  to  explore  migrating  code  from  an  in-house 
project  to  support  the  maturing  Information  Operations  (10)  Planning  Capabilities  programs, 
IWPC  and  Information  Operations  Navigator  (ION).  These  programs  were  being  installed  at 
various  COCOM  locations  and  specific  areas  of  common  capability  between  current  Air  Force 
and  future  COCOM  needs  were  identified.  The  common  capabilities  included  Intelligence 
Preparation  of  the  Battlespace  (IPB);  10  Strategy  and  Candidate  10  Campaign  Targets 
(Strategy/Targets);  10  Mission  Planning  (10  Missions);  and  Mission  Execution  Monitoring  and 
Assessment  (Assessment). 

The  purpose  of  the  code  migration  was  to  leverage  work  already  performed  in  the  area  of 
visualizations  of  Air  Operations  in  support  of  Strategic  Planning  to  further  the  10  Planning 
Capabilities  program.  The  candidate  software  provided  the  following  functionality  in  support  of 
Strategy  Planning  needs: 

•  Data  import  and  filtering  (e.g.  ATO,  intelligence  data,  etc) 

•  Data  display  on  user-selected  map  backgrounds 

•  User-selected  layering  of  the  capability  displays  (i.e.  ability  to  de-clutter) 
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•  Visualization  of  notional  operational  effects  of  employing  capabilities  against  specific 
targets,  shown  in  a  time-ordered  sequence  with  playback  (e.g.  nodes  affected  and  when) 

•  Visualization  of  temporal  and  spatial  integration  of  capabilities  into  Operation  Plan 
(OPLAN)  “What  if’  analysis  by  changing  some  data  variables  and  producing  different 
display  results 

•  On-line  help  files,  some  with  capability  specifications  or  OPLAN  references 

The  following  features  were  incorporated  into  the  Teneo  prototype:  1)  launch  Teneo  from  the 
IWPC  main  menu,  2)  allow  the  user  to  view  targets  from  IWPC  through  a  special  layer  inside 
Teneo,  3)  pass  messages  from  IWPC  via  a  rudimentary  publish- subscribe  (“pub-sub”) 
framework  using  web  services,  4)  retrieve  target  data  via  a  web  service  interface  from  IWPC  and 
MIDB  based  on  a  user-defined  geographic  area  of  interest,  5)  retrieve  ATOs  via  a  web  service 
interface  developed  from  a  .NET  adapter  for  TBONE,  and  6)  repaired  the  existing  United  States 
Message  Traffic  Format  (USMTF)  parser  to  expect  any  number.  Finally,  the  IWPC  architecture 
(Teneo  enhanced)  was  evaluated  to  understand  the  effectiveness  of  an  integration  effort. 
Modifications  to  the  existing  architecture  were  proposed  to  improve,  for  example,  web  services. 

The  purpose  was  to  evaluate  the  client  software  and  the  architecture  as  a  whole.  The  technical 
(Analysis)  Report  and  Software  Product  Specification  were  delivered  in  June  of  2007. 


3.7  INFORMATION  OPERATIONS  PLANNING  CAPABILITY  -  EXPERIMENT 

lOPC-X  was  a  risk  reduction  capability  to  develop  a  modem  SOA-based  architecture  for  IWPC 
and  to  refine  future  technical  and  operational  requirements.  Primary  operational  and  technical 
direction  was  provided  by  the  Joint  Forces  Command  (JFCOM)  Engineering  Staff  Section  (J7) 
Vision  Technical  Integrative  Product  Team.  The  lOPC-X  environment  enabled  demonstrating 
COA  Sketch  as  a  plug-in  capability  to  the  SOA-based  IWPC.  The  resulting  lOPC-X  prototype 
provided  the  following: 

■  A  software  Net-Centric  infrastmcture  prototype  enabling  integration  of  new  capability 
modules  (CM) 

■  A  pluggable  infrastmcture  of  core  IWPC  tools  and  10  analysis  capabilities 

■  Alignment  with  the  Net-Enabled  Command  Capability  (NECC)  and  Net-Centric  Core 
Enterprise  Services  (NCES)  standards  and  capabilities 

A  use  case  diagram  is  provided  in  Figure  14.  A  detailed  description  of  this  task  is  provided  in 
Appendix  C  Volume  II. 
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Figure  14  lOPC-X  Operational  Use  Case 


The  lOPC-X  SDK  in  Appendix  B  Volume  II  contains  an  overview  of  the  lOPC-X  Architecture  and 
summarizes  the  Net-Centric  Standards  that  were  used.  The  standards  for  lOPC-X  are  registered 
with  DoD  Information  Technology  Standards  Registry  (DISK)  and  follow  the  guidance  provided 
in  the  Net-Centric  Operational  Warfare  Reference  Model  (NCOW-RM).  Reasoning  and 
correlation  of  the  standards  followed  are  detailed  in  the  appropriate  sections  of  the  SDK. 

The  SDK  includes  a  discussion  of  the  Plug-in  Infrastructure  based  on  the  Eclipse  Rich  Client 
Platform  (RCP)  and  Registration  of  the  plug-ins  for  discovery  of  the  CMs.  The  SDK  moves  from 

TM  TM 

the  client  side  to  discussion  of  the  J2EE  Enterprise  JavaBeans  (EJB  )  3.0  compliant  data 
access  tier  and  its  use  of  the  JENA  library  set  and  Oracle  database  for  Ontological  persistence  of 
information.  With  understanding  of  the  data  access  tier,  the  SDK  returns  to  discussion  of  the 

TM 

middle  tier  to  cover  the  lOPC-X  Web  Services  which  act  as  a  Facade  onto  the  J2EE  session 
bean  discussed  in  the  data  access  tier  section. 


Security  considerations  are  discussed  in  their  appropriate  sections.  Throughout  the  SDK, 
Sequence  diagrams  are  provided  to  visually  reflect  uses  of  the  lOPC-X  interfaces  being 
discussed.  lOPC-X  specific,  as  well  as  open  source  code,  examples  and  tutorials  have  been 
provided  or  referenced  to  ensure  complete  understanding  of  how  to  properly  build  lOPC-X 
compliant  components.  The  supporting  Unified  Modeling  Language  (UML)  design  diagrams  and 

TM 

Javadocs  have  been  provided  as  sections  to  the  SDK. 
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3.7.1  lOPC-X  ARCHITECTURE  OVERVIEW 


Figure  15  illustrates  the  lOPC-X  architecture  components.  The  lOPC-X  architecture  is  a  fully 

TM  TM 

Net-Centric  compliant  design  which  leverages  a  J2EE  EJB  3.0  compliant  infrastructure  for 
ease  in  Authentication,  Authorization  and  Scalability.  The  J2EE™  session  beans  are  also  exposed 
via  Web  Service  interfaces.  The  ontology-based  backend  leverages  the  JENA  library  set  in  order 
to  address  the  requirements  of  the  Net-Centric  Data  Strategy. 
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Figure  15  lOPC-X  Architecture  Components  (Migration  to  NCES) 


The  client  architecture  supports  an  evolutionary  development  path  and  re-use  of  existing  Java™ 
and  .Net  developed  “Fat  Clients.”  The  lOPC-X  design  includes  an  Open  Services  Gateway 
Initiative  (OSGi)  compliant  plug-in  infrastructure  based  upon  the  Eclipse  RCP. 


lOPC-X  client  components  included  the  following: 


■  lOPC-X  RCP  Workbench  which  acts  as  a  ‘baseline’  lOPC-X  installation.  All  client  plug¬ 
ins  will  use  the  workbench  as  their  target  platform.  The  workbench  initializes  the  main 
client  window,  menus,  and  toolbars,  providing  a  predictable  environment  for  the  plug-ins. 

■  The  Data  Access  plug-in  provides  a  locally  replicated  copy  of  the  ontology  in  an  effort  to 
reduce  memory  consumption  and  network  traffic.  The  plug-in  has  the  same  interface  as 


26 


the  web  serviee,  but  references  its  own  ontology  and  prevents  all  plug-ins  from  having  to 
maintain  a  separate  instance  of  the  ontology  and  keep  track  of  updates.  However,  use  of 
this  plug-in  is  not  mandatory  and  a  client  plug-in  could  reference  the  web  service 
interface  directly. 

■  The  Login  &  Security  plug-in  provides  authentication  routines  and  login  handling  in  the 
workbench.  This  plug-in  provides  the  login  information  to  any  other  plug-ins  that  need  to 
access  it  (such  as  the  Data  Access  plug-in). 

■  The  Dynamic  update  plug-in  provides  client  updates  transparently.  No  additional 
software  needs  to  be  written  to  allow  dynamic  update  -  this  capability  is  provided  by  the 
workbench  and  the  OSGi  framework. 

3.7.2  EXTERNAL  INTERFACES 

A  key  element  for  demonstrating  the  lOPC-X  framework  and  COA  Sketch  was  access  to  and  the 
use  of  operationally  relevant  data  sources.  This  was  accomplished  in  part  through  design  and 
development  of  net-centric  data  transfer  interfaces  from  the  IWPC.  To  further  enhance  data 
exchanges,  interfaces  to  additional  external  systems  of  record,  MIDB,  JTT  and  the  TBMCS 
FrOB  Service  were  investigated  for  web  service  interface  design  and  development  under  the 
lOPC-X  solution. 

Technical  interchange  meetings  were  conducted  as  required  to  facilitate  understanding  and 
integration  of  the  chosen  systems  of  record.  Unfortunately,  interface  implementation  for  the  most 
operationally  relevant  system  of  record  for  demonstration  purposes,  MIDB,  was  fraught  with 
difficulties  due  to  ongoing  and  numerous  changes  to  the  MIDB  software  interfaces,  as  well  as, 
downsizing  of  external  support  personnel  from  the  MIDB  System  Program  Office  (SPO).  MIDB 
was  undergoing  a  significant  redesign  and  development  efforts  throughout  the  attempted 
integration  and  lOPC-X  could  not  keep  pace  with  those  changes  under  the  originally  planned 
budget.  JTT  likewise  was  in  the  middle  of  its  Netcentric  Key  Performance  Parameter  (KPP) 
interface  updates  and  proved  to  be  a  moving  target  with  emerging  and  changing  interface 
definitions.  While  rudimentary  transfer  of  information  from  the  TBMCS  FrOB  service  was 
accomplished,  lack  of  budget  and  further  SME  feedback,  noting  that  the  FrOB  service  was  not 
actually  being  leveraged  to  the  intended  extent,  finalized  the  development  of  this  interface  prior 
to  integration  into  the  COA  Sketch  user  interface.  All  data  transfer  interfaces  are  documented  in 
the  COA  Sketch  UML  Design  bundle  were  designed  as  web  service  interfaces  that  incorporated 
the  relevant  guidance  and  standards  defined  in  the  DoD  NCOW-RM. 

Appendix  D  contains  the  Use  Cases  and  Requirements  artifacts  for  the  external  interfaces.  Also 
provided  under  separate  cover  in  electronic  format  is  the  generated  experimental  code  base. 


3.8  COLLABORATION 

3.8.1  COLLABORATION  IN  THE  AOC  CONTEXT 

The  Air  Force  is  increasingly  using  dynamic  effects-based  approaches  for  monitoring,  assessing, 
planning  and  executing  military  operations.  These  approaches  levy  new  demands  on  personnel  in 
the  AOC  and  in  reach-back  organizations.  In-depth  collaboration  requiring  immediate  shared 
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access  and  manipulation  of  information  about  the  operational  environment,  mission  exeeution 
and  assessment  is  necessary  between  these  personnel  who  are  often  loeated  in  physically 
disparate  locations.  The  required  information  to  support  effects-based  approaehes  consists  not 
only  of  data,  but  also  of  context.  Understanding,  updating  and  synehronization  aetivities 
performed,  and  monitoring  effects  upon  this  systems-of-systems,  requires  a  tailorable 
eollaboration  environment  -  one  that  supports  a  natural  collaborative  workflow  between  both 
eollocated  and  remote  users  in  support  of  near  real-time  eoordinated  produetion  of  AOC  work 
produets. 

An  investigation  into  the  leading  collaboration  tools  in  industry  and  government  determined  that 
none  of  the  major  players  in  the  COTS  arena,  ineluding  the  designated  (DoD  CIO 
MEMORANDUM,  Feb  02,  2009)  DoD  Enterprise  Collaboration  Services  provided  by  DISA  and 
known  as  E-CollabCenter  and  Defense  Conneet  Online  (DCO)  are  extensible  enough  for  use  in 
the  development  of  coneepts  to,  for  example,  faeilitate  production  of  end  product  focused  objects 
and  attributes  during  eollaboration.  This  finding  brought  to  focus  the  Australian  Department  of 
Defence,  DSTO  “LiveSpaees”  for  use  as  a  eollaboration  tools  framework.  LiveSpaees  is  founded 
on  human-eentered  design  prineiples,  and,  while  LiveSpaees  is  not  thin  elient  based  like  other 
offerings,  the  architeeture  is  extensible  and  supports  ubiquitous  design  (early  proof  of  eoneepts 
have  established  and  extended  the  LiveSpaees  environment). 

“A  LiveSpace  is  a  technology-enhanced  collaboration  space  for  a  team  of people.  The 
purpose  of  a  LiveSpace  is  to  integrate  technologies  that  help  people  work  together:  To 
bring  these  technologies  together  into  a  supporting  system  that  becomes  part  of  the 
background,  rather  than  the  more  common  situation  where  these  technologies  appear  as 
a  set  of  disparate,  idiosyncratic  and  quirky  hardware  gadgets  and  software  applications.  ” 
(Phillips,  2008). 

SPVT  eonducted  a  eollaboration  technology  assessment  event  to  provide  the  AFRL  a  better 
understanding  of  distributed  eollaboration  technology  effectiveness  in  a  USAF  AOC  Strategy 
Division  planning  context.  The  event  was  held  September  14-18,  2009  at  distributed  loeations  - 
SRA  in  Dayton,  OH  and  Louisianan  State  University  -  Shreveport  (LSU-S)  in  Shreveport,  LA. 

SPVT  Collaboration  event  partieipants  provided  a  breadth  of  experienee  aeross  the  AOC 
strategy,  operational  assessment,  combat  operations,  influenee  operations  and  intelligence  roles. 
Participants  were  a  mix  of  active  duty  and  retired  USAF  personnel  and  government  contractors. 
The  event  also  afforded  the  opportunity  to  showcase  AFRL  “tools  that  collaborate.”  AFRL 
technologies  sueh  as  COA  Sketch  and  SMART  support  the  AOC  strategy  planning  process  as 
well  as  collaborative  interactions  for  multiple,  eoneurrent  users  within  and  across  those 
technologies. 

The  collaboration  study  focused  on  the  information  exchanges  of  AOC  strategy  planners  and 
intelligenee  analysts  within  a  work  centered  eollaboration  environment.  In  theory,  by  allowing 
the  manipulation,  tracking  and  production  of  work  product  objects  and  attribute  details  during 
collaboration  within  the  intuitive  extended  LiveSpaees  environment,  effective  distributed 
communication  can  occur.  The  LiveSpaees  environment  removes  the  dependency  for  a  single 
person  (reeorder)  tasked  to  capture,  the  sometimes  rapid-fire  and  numerous  details  of  the 
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collaborative  effort  into  the  final  work  product,  often  resulting  in  improved  throughput  and  a 
higher  level  of  accuraey. 

For  the  purposes  of  assessing  the  projeet’s  hypothesis, 

“The  collaboration  environment  enables  a  distributed  strategy  plans  session  which  is  as 
effective  as  that  developed  by  collocated  planners,  ” 

two  questions  had  to  be  answered.  First,  how  well  did  the  eollaboration  teehnology,  i.e. 
LiveSpaees  environment,  support  individual  and  team  strategy  planner  work?  Seeond,  how  well 
did  the  software  tools  support  strategy  planner  work  (assuming  these  tools  “eollaborate”)? 

Appendix  E  eontains  a  more  in-depth  analysis  and  overview  of  the  eollaboration  assessment 
event. 


3.8.2  COLLABORATION  IN  A  DISTRIBUTED  WORKSHOP 

The  culminating  event  for  SPVT  collaboration  was  conducting  a  distributed  workshop  for  The 
Teehnieal  Cooperation  Program  Technieal  Panel  2  on  Command  Information  Interfaces  (TTCP 
C3I  TP2)  using  LiveSpaees  collaboration  environment.  The  meeting  focused  on  the  discussion  of 
results  from  reeent  US  AFRL,  Australian  (AU)  Defense  Seienee  and  Technology  Organization 
(DSTO)  and  Defence  Research  and  Development  Canada  (DRDC)  experiments  involving 
LiveSpaees  technology.  This  activity  was  preceded  by  four  preliminary  aetivities  to 
progressively  build  upon  establishing  the  final  meeting  spaee.  The  four  preliminary  activities  and 
one  final  activity  are  summarized  in  chronologieal  order  ineluding  the  coordination  tasks 
required  between  SRA,  AU  DSTO  and  CA  DRDC  in  order  to  sueeessfully  conduet  eaeh  aetivity. 

Activity  1  -  Establish  Communications 

Preparations  for  the  TTCP  C3I  TP2  workshop  began  with  Activity  1  on  October  20,  2009. 

Several  tasks  were  required  leading  up  to  and  through  this  aetivity  in  whieh  the  goal  was  to 
establish  a  LiveSpaees  and  Defense  Conneet  Online  (DCO)  conneetion  between  Australia  and 
US  AFRL  (at  SRA  Dayton)  over  the  open  internet. 

Updated  LiveSpaees  software  and  documentation  was  provided  to  SRA  from  AU  DSTO.  The 
update  ineluded  the  proeedure  to  federate  LiveSpaee  servers.  SRA  test  the  federated  servers 
internally  with  exeellent  results.  Next,  SRA  eonfigured  their  internal  network  (Adroit)  to  allow 
only  AU  DSTO  Internet  Protoeols  (IPs)  aeeess.  SRA  set  up  a  federated  server  where  the  primary 
LiveSpaees  server  was  in  Australia  (AU  DSTO)  and  SRA  was  the  seeondary  LiveSpaees  server. 
No  eneryption  or  Virtual  Private  Network  (VPN)  setup  was  used  for  Activity  1. 

The  LiveSpaees  functionality  test  for  Aetivity  1  was  completed  sueeessfully.  Audio  was  initially 
conducted  via  telephone.  However,  AU  DSTO  experienced  an  echo,  so  the  teams  switched  to  the 
Skype  Voiee  Over  Internet  Protocol  (VOIP)  with  better  results.  No  other  issues  were 
experienced. 


29 


Activity  2  -  Exercise  Communications 

Activity  1  continued  October  22,  2009  with  a  goal  of  exercising  the  LiveSpaces  and  DCO 
technologies  to  ensure  a  robust  connection  (meeting  place).  The  DCO  connection  was  successful. 
Capabilities  within  each  technology  performed  well.  No  encryption  was  established  for  this 
activity.  However,  Activity  3  planned  to  establish  encryption,  so  following  Activity  2  SRA 
began  coordinating  a  firewall-to-firewall  VPN  with  AU  DSTO  through  their  system 
administrator. 

Activity  3  -  Establish  VPN 

Activity  3  was  conducted  on  November  4,  2009  with  a  goal  of  establishing  a  secure  VPN 
connection  between  AU,  US,  and  CA.  A  successful  connection  would  be  followed  by 
demonstrating  that  LiveSpaces  and  DCO  work  over  the  connection  as  was  performed  in  Activity 
2.  In  preparation  for  this  activity,  the  AU  DSTO  system  administrator  coordinated  extensively 
with  the  SRA  system  administrator.  While  the  VPN  was  not  completely  configured  for  this 
event,  the  secure  connection  was  established  the  day  after  Activity  #3. 

Activity  4  -  Test  Meeting  Protocol 

On  November  5,  2009,  Activity  4  was  conducted  to  work  through  the  distributed  meeting 
protocol.  US  AFRL,  AU  DSTO  and  CA  DRDC  were  all  represented.  The  first  action  item 
included  testing  the  firewall-to-firewall  VPN.  The  test  was  successful.  Next,  the  TP2  team 
reported  on  preparations  for  and  the  success  of  Activities  1  through  3.  This  discussion  included 
the  reporting  on  the  advantages  and  disadvantages  in  going  from  the  open  internet  connectivity 
to  Secure  VPN  connectivity  (with  respect  to  security,  performance,  limitations,  etc).  Activity  4 
concluded  with  the  TP2  team  coordinating  a  final  date  for  the  distributed  workshop. 

Activity  5  -  Conduct  Distributed  Meeting 

The  final  activity,  Activity  5,  was  a  demonstration  that  a  virtual  distributed  meeting/workshop 
could  be  conducted  between  the  TP2  members  utilizing  LiveSpaces,  DCO,  and  other 
technologies  over  secure  VPN  and/or  the  open  internet.  SRA  supported  the  meeting  through  a 
LiveSpaces  federated  site  at  the  SRA  Dayton  facility  for  US  AFRL.  Preparations  for  this  activity 
included  unsuccessfully  establishing  a  firewall-to-firewall  VPN  working  between  SRA  and  CA 
DRDC  (Note:  CA  DRDC  used  a  FreeBSD-based  FOSS  firewall  called  ‘pfSense’  and  no  support 
instructions  existed  for  establishing  a  VPN  with  the  SRA  Sonic  Wall  firewall.  The  VPN 
connection  between  SRA  and  AU  DSTO  was  successful,  however,  as  was  the  connection 
between  AU  DSTO  and  CA  DRDC). 

The  TP2  workshop  was  represented  by  US  AFRL,  AU  DSTO  and  CA  DRDC  and  conducted 
November  23,  2009,  through  LiveSpaces  and  DCO  with  audio  teleconference  as  required 
(outside  DCO).  Each  represented  organization  reported  on  recent  collaboration  technology 
experiment  results  or  other  relevant  activity.  Preliminary  human  performance  and  technical 
results  were  described  for  the  Collaboration  in  the  AOC  Context  task.  AU  DSTO  initiated  a 
relatively  high  bandwidth  video  to  test  overall  system  response  and  performance.  The  TP2 
members  in  attendance  discussed  observed  collaboration  system  effectiveness  and  performance 
issues  for  LiveSpaces  and  DCO,  as  well  as  related  advantages,  disadvantages,  benefits  and  costs, 
as  appropriate. 
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The  TTCP  C3I  TP2  workshop  was  considered  a  success  with  respect  to  the  initial  goal  of 
conducting  a  virtual  distributed  meeting/workshop  utilizing  LiveSpaces,  DCO  and  other 
technologies. 
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4.0  RESULTS  AND  DISCUSSION 


4.1  USER  INFORMATION  AND  DECISION  REQUIREMENTS 

The  SPVT  program’s  human-centered  focus  ensured  warfighter  interests  were  at  the  heart  of 
research  and  design  decisions.  The  Phase  I  cognitive  work  requirements  analysis  and  Phase  II 
user  information  and  decision  requirements  analysis  resulted  in  the  team’s  solid  grounding  in 
work  context  for  AOC  SD  personnel.  While  most  efforts  were  targeted  at  building  knowledge  of 
work  for  the  SPT  within  the  SD,  information  was  also  acquired  on  SGT  and  OAT,  as  well  as  the 
Combat  Plans  Division. 

The  foundation  for  user  requirements  was  generated  early  and  built  upon  incrementally  through 
each  task.  The  initial  analysis  of  doctrine  and  related  information  was  used  to  initiate  discussions 
with  warfighters  regarding  work  aids,  information  and  decision  requirements.  One  elicitation 
opportunity  occurred  at  the  Warfighter  Assessment  Workshop  (WAW)  in  April  2006  and 
resulted  in  50  requirements.  Twelve  high-level  COA  Sketch  requirements  were  generated  from 
aggregation  of  WAW  requirements  and  other  sources  such  as  found  with  the  AOC  Strategy  and 
Assessment  Requirements  sub-Working  Group.  Additional  requirement  analyses  were  conducted 
for  CEP  and  JAST,  resulting  in  59  and  303  requirements,  respectively.  More  detailed  COA 
Sketch  requirements  later  evolved  from  the  aggregate  of  these  requirement  analyses.  The  core 
requirements  discussed  here  included  over  500  AOC  operational  requirements,  which  are 
documented  in  Appendix  A. 


4.2  COMMON  EFFECTS  PICTURE 

CEP  provided  senior  leaders  and  their  staff  a  capability  to  understand  the  operational 
environment  and,  when  necessary,  the  elements  comprising  a  particular  condition  or  state.  The 
concepts  comprising  CEP  were  well-received  by  the  warfighter  communities  and  were  further 
steered  by  Lt.  Gen.  Charles  R.  Heflebower  (Ret.),  one  of  the  senior  mentors.  CEP  addressed  a 
warfighter  information  visualization  need,  but  the  lack  of  data  feeds  to  supply  the  technology 
forced  this  effort  to  be  set  aside  in  favor  of  a  subset  of  the  concept  which  could  be  addressed 
through  existing  or  planned  data  feeds.  Strategic  Lines  of  Effect  visualization  was  chosen  as  a 
key  subset  of  the  CEP  to  pursue  further.  Many  CEP  concepts  were  matured  and  revisited  in  other 
SPVT  concepts  such  as  GEM-S  and  COA  Sketch. 


4.3  GLOBAL  EFFECTS  MANAGEMENT  SYNCHRONIZATION 

GEM-S  resulted  in  several  innovative  visualization  concepts  for  effects  management  on  a  global 
scale.  Some  concepts  were  based  on  earlier  CEP  designs  and  some  concepts  evolved  from 
interaction  with  the  JIOWC  user  community.  The  GEM-S  prototype  was  developed  with  a  fully 
interactive  user  interface,  although  with  no  data  storage  or  handling  capabilities. 

The  prototype  capabilities  were  well  received  and,  conceptually,  the  GEM-S  prototype  provided 
an  informative  view  onto  operations  at  a  large  scale.  Of  primary  operational  concern,  however. 
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were  the  data  sources  required  to  feed  GEM-S.  A  single  data  source  clearly  was  not  possible 
across  multiple  agencies,  organizations  and  programs,  and,  while  a  suite  of  data  sources  was  a 
more  likely  scenario,  the  challenge  remained  to  access  numerous  stove-piped  systems, 
inconsistent  formats  and  manual  records.  Ultimately,  the  data  required  to  support  and  maintain 
GEM-S  was  considered  an  unattainable  task  and  further  development  stopped  as  a  standalone 
capability. 


4.4  JAOP  AOD  STATUS  TOOL  (JAST) 

JAST  was  the  product  of  a  need  to  complete  a  significant  information  feedback  path  from  CO  to 
the  SD  by  providing  useful  combat  planning  and  execution  status  data  correlated  to  a  published 
Joint  Air  Operations  Plans  (JAOP)  and  the  daily  Air  Operations  Directives  (AOD).  Termination 
of  the  TBONE  program,  however,  just  prior  to  IWPC  deployment  meant  JAST  had  to  be 
disabled  in  the  IWPC  v4.2  (i.e.  the  required  data  feed  to  populate  JAST  did  not  exist).  JAST  was 
fully  integrated  with  IWPC  software  and  deployed  to  warfighters,  however,  the  capability  was 
simply  never  “turned  on”  and  thus  users  were  never  made  aware  that  the  capability  exists  should 
appropriate  data  feeds  become  available  in  the  future. 


4.5  COURSE  OF  ACTION  (COA)  SKETCH 

Course  of  Action  (COA)  Sketch  was  focused  on  the  desire  to  support  “visually”  developing  a 
strategy  plan.  The  work-centered  focus  brought  together  essential  warfighter  strategy  planning 
processes  into  a  single  technology  with  the  capability  to  expose  in  real-time  work  products  to 
other  warfighters.  While  warfighters  were  excited  with  the  prospect  of  working  on  a  plan 
simultaneously  at  the  attribute  level  and  developing  artifacts  within  that  same  environment,  the 
real  power  of  COA  Sketch  became  evident  when  warfighters  validated  that  the  capability 
supported  their  work  (rather  than  the  warfighters  having  to  develop  new  work  methods  which  so 
often  happens  with  technology-focused  capabilities). 

Key  COA  Sketch  features  were  the  familiar  hierarchical  plan  structure  and  corresponding 
synchronization  view.  A  map  sketch  view  with  objects  linked  to  the  plan  and  synchronization 
views  provided  a  complete  temporal  and  geospatial  picture  of  the  plan.  Built  on  a  common  data 
model,  manipulations  in  one  view  were  manifest  in  other  views  -  emphasizing  the  multiple 
perspectives  on  data  design  objective. 

COA  Sketch  concepts  were  further  validated  with  respect  to  supporting  strategy  planning  work 
with  transition  to  two  programs.  The  first  transition  occurred  November  2008  when  COA  Sketch 
was  integrated  into  the  lOPC-X  database  ontology  which  allows  data  to  be  exchanged  freely  with 
other  lOPC-X  Capability  Modules.  The  database  ontology  was  a  risk  reduction  effort  to  better 
understand  how  well  ontologies  provided  data  storage  and  manipulation.  The  lOPC-X  program 
moved  from  a  USAF-focused  effort  to  a  Joint  program,  VisIOn,  opening  the  opportunity  for 
exposure  of  COA  Sketch  to  other  services.  COA  Sketch  was  the  primary  planning  module  for 
use  in  VisIOn,  which  continues  to  explore  alternative  database  ontology  methods  to  serve  as  the 
data  storage  and  manipulation  foundation  upon  which  COA  Sketch  can  operate. 
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In  September  2009,  the  second  transition  occurred.  The  USSTRATCOM  multi-service  strategy 
planning  program  of  record,  ISPAN,  requested  COA  Sketch  as  a  means  to  enhance  visual  plan 
development  within  the  ISPAN  plarming  component.  The  ISPAN  program  was  actively  engaged 
in  identifying  technologies  which  would  quickly  benefit  the  strategy  planning  capability  within 
ISPAN.  COA  Sketch  offered  the  ability  to  accelerate  ISPAN  user  interface  development  by 
applying  COA  Sketch  user  interfaces,  in  whole  or  part,  as  an  alternate  view  onto  ISPAN  data. 

4.6  TENEO 

Teneo  was  a  prototype  and  was  not  intended  for  production  use.  While  the  concepts  that  Teneo 
presented  were  excellent,  the  implementation  had  some  problems.  Teneo  was  meant  to  be  a 
prototype  and  not  intended  for  release  or  integration.  The  software  was  developed  very  quickly 
for  a  specific  audience  and,  as  such,  made  many  assumptions.  These  assumptions  precluded  any 
error  handling  or  concern  for  the  needs  of  a  generic  user.  Errors  were  generally  handled  by 
application  failure  and  subsequently,  exiting  the  program.  As  a  prototype,  code  comments  were 
neither  present  nor  expected  and  the  provided  documentation  reflected  the  concepts  of  Electronic 
Warfare  (EW),  rather  than  providing  insight  into  the  software  development.  The  evaluation 
resulted  in  the  recommendation  to  completely  redesign  and  rewrite  Teneo. 


4.7  INFORMATION  OPERATIONS  PLANNING  CAPABILITY  -  EXPERIMENT 

lOPC-X  was  a  risk  reduction  capability  to  develop  a  modem  SOA-based  architecture  for  IWPC 
to  refine  future  technical  and  operational  requirements.  COA  Sketch  and  SMART  were 
integrated  as  capabilities  within  the  lOPC-X  framework.  The  lOPC-X  prototype  was  used  in  the 
Pirate’s  Daggers  Exercise  2008  to  demonstrate  the  SOA  architecture  and  the  plug-in 
infrastracture. 

Determining  the  best  way  ahead  for  COA  Sketch/IOPC-X  capability  framework  requires  more 
research.  An  end-to-end  review  of  COA  Sketch/IOPC-X  is  highly  recommended  prior  to  full- 
scale  design  for  the  potential  next  generation  platform,  COA  Sketch/aXiom.  At  a  minimum  the 
data  model,  and  particularly  the  date  and  constraint  model,  should  be  reviewed  with  the  goal  of 
expressing  queries  and  pattern  matches  concisely.  This  effort  should  produce  a  flatter,  more 
redundant,  class  model  with  fewer  classes  and  less  nesting  of  objects. 

The  COA  Sketch/IOPC-X  Web  Service  Description  Language  (WSDL)  interface  will  need  to  be 
reviewed  along  with  the  data  model.  The  current  design  is  a  general  purpose  Create,  Update, 
Delete  model.  System-level  study  is  needed  to  determine  if  more  business-level  tasks  can  be 
defined  at  the  web  service  layer.  In  addition,  the  serialization  constraints  inherent  in  the  current 
data  model  need  to  be  removed.  Many  object  classes  cannot  currently  be  serialized  as  stand¬ 
alone  objects  -  they  require  additional  document  portions.  This  approach  must  be  redesigned  so 
that  the  data  model  objects  can  be  used  in  a  more  encapsulated  fashion. 

Finally,  the  lack  of  support  for  ontological  data  formats  (SPARQL  and  SPARQL  result-set 
XML)  in  the  client  application  is  a  shortfall.  The  data  interchange  between  some  plug-ins  such  as 
COA  Sketch  and  server  is  problematic.  Pushing  the  responsibility  for  query  execution  and 
processing  to  the  client  tier  goes  against  the  theory  of  N-tiered  architectural  design  and  violates 
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the  assumption  of  a  course-grained,  optimistic  system.  Expectations  for  the  capabilities  of  an 
ontological  data  access  client  must  be  recalibrated  and  agreed  upon.  One  might  consider  the 
COA  Sketch  service  the  true  ontological  client  and  the  COA  Sketch  thin  client  merely  a  display 
layer.  In  any  case,  SPARQL  result  sets  are  not  ideal  for  passing  data  in  a  client  /  server  system. 
Other  ontological  technologies  such  as  RDF/XML  may  be  more  suitable,  but  replacing  a  well- 
known  and  understood  technology  like  WSDL  with  RDF/XML  requires  more  research. 


4.8  COLLABORATION  IN  THE  AOC  CONTEXT 

Effects-based  approaches  for  monitoring,  assessing,  planning  and  executing  military  operations 
levy  new  demands  on  personnel  in  the  AOC  and  in  reach-back  organizations.  Collaboration 
requiring  immediate  shared  access  and  manipulation  of  information  about  the  operational 
environment,  mission  execution  and  assessment  is  necessary  between  these  personnel  who  are 
often  located  in  physically  disparate  locations.  A  natural,  collaborative  workflow  is  necessary  to 
support  effects-based  approaches  which  demand  human  interaction  with  both  data  and  context. 

The  SPVT  collaboration  assessment  event  demonstrated  “true”  distributed  operations  for  a 
USAF  Strategy  Planning  context.  The  LiveSpaces  technology  proved  to  have  great  potential  for 
use  in  distributed  planning  operations,  although  operational  instabilities  masked  system 
effectiveness.  A  LiveSpaces  enhancement,  federated  LiveSpaces,  was  available  following  the 
collaboration  assessment.  Post-event  tests  demonstrated  the  LiveSpaces  federated  servers  greatly 
improved  performance,  in  particular,  LivePoint  functionality.  The  custom  audio  and  video 
capabilities  improved  slightly  with  remaining  performance  issues  due  to  component  design 
rather  than  the  LiveSpaces  environment. 

Several  discussion  points  brought  forth  by  the  users  were  artifacts  of  the  non-federated 
LiveSpaces  environment.  Additional  discussion  points  were  attributable  to  known  human 
interface  design  issues  which  were  magnified  by  interactions  with  the  aforementioned 
environment  instabilities.  Major  points  included  the  need  for  a  LivePoint  mouse  pointer  “label”; 
system  control  procedures  and  mechanisms,  i.e.  how  to  establish,  maintain  and  coordinate 
system  control  as  well  as  identification  of  who  is  in  control;  and  creating  a  frame  of  reference  for 
Screen  Sharing,  i.e.  who  is  sharing  with  whom. 
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5.0  SUMMARY 


SPVT  was  a  multi-year  effort  focused  on  improving  warfighter  effectiveness  in  the  AOC 
Strategy  Planning  context  through  work-centered  understanding  of  warfighter  information  and 
decision  requirements.  The  primary  dimensions  addressed  included:  how  decisions  are  made  in 
the  Strategy  Division  in  performing  work;  how  work  products  are  developed;  how  work  is 
managed;  and  the  types  of  collaborations  and  interactions  that  are  necessary. 

SPVT  tasking  followed  a  human-centered,  systems  engineering  process,  beginning  with  defining 
operational  user  information  and  decision  making  requirements  through  a  combination  of 
modeling  work-relevant  documentation  and  interviewing  warfighters  (on  site  with  warfighter  in 
role  and  off  site  with  warfighter  role  playing).  Findings  from  the  User  Requirements  Analysis 
drove  the  next  set  of  activities.  (Note  the  team  continued  to  build  on  the  user  information 
requirements  as  new  documentation  and  warfighter  interviews  became  available.)  Initial 
concepts  focused  on  developing  an  effects-based  dashboard.  Common  Effects  Picture  (CEP), 
suitable  for  the  Commander  to  obtain  a  quick  and  accurate  assessment  of  the  battlespace.  A  key 
characteristic  of  CEP  was  transparency  from  the  highest  level  of  information  aggregation  into  the 
supporting  data,  methods  and  analyses. 

A  logical  extension  of  CEP  was  to  a  joint  service  effects  management  system.  Global  Effects 
Management  -  Synchronization  (GEM-S),  an  envisioned  single  collection  point  for  organizing 
and  deconflicting  multi-service  global  operations.  GEM-S  provided  a  venue  to  explore  interface 
and  visualization  concepts  for  the  many  interactions  among  agencies,  activities  and  effects. 

Following  the  goal  to  support  the  Strategy  Division,  the  next  SPVT  task  focused  on  enhancing 
the  AOC  planning  system  of  record,  IWPC,  by  bringing  near  real-time  ATO  execution 
information  from  Combat  Operations  directly  to  the  Strategy  Division  rather  than  waiting  on 
slow  and  sometimes  incomplete  reports  from  the  Operations  Assessment  Team.  The  JAOP  AOD 
Status  Tool  (JAST)  was  integrated  with  IWPC  4.2.5  eSync/CPT  capability  modules  and 
instantiated  through  a  series  of  basic  visualizations. 

Building  on  supporting  the  Strategy  Planner,  Course  of  Action  Sketch  (CO A  Sketch)  took  a 
previously  text-based,  manual,  single  person  bottlenecked  process  and  transformed  it  to  a 
graphical,  human-supported  automation,  collaborative  technology.  COA  Sketch  provides  a 
human- focused  electronic  work  environment  for  the  warfighter  to  flexibly  and  adaptively 
collaborate  in  JAOP  development.  Strategy  planners  have  the  capability  to  capture  the  plan  as  it 
is  developed.  And  while  simple  in  concept,  COA  Sketch  brought  together  capabilities 
warfighters  most  desired  during  strategy  planning  such  as  Shared  awareness;  Graphics  that  are 
data  aware;  Collaborative  development;  and  Support  for  development  toward  a  team  mental 
model.  COA  Sketch  transition  to  two  separate  programs  provided  the  validation  that  decision- 
centered  visualization  support  to  the  AOC  Strategy  Planner  was  accomplished. 

While  COA  Sketch  was  an  evolving  technology,  TENEO  was  brought  to  the  SPVT  program  for 
evaluation  as  a  capability  enhancement  to  IWPC.  TENEO  included  several  planning  capabilities 
similar  in  concept  to  COA  Sketch  but  much  less  robust  from  a  software  development 
perspective.  The  impetus  for  the  project  was  to  determine  whether  TENEO  capabilities  were 
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mature  enough  to  integrate  with  IWPC.  The  short  answer  was  “no”  and  the  customer,  after 
learning  of  COA  Sketch,  proposed  the  following  opportunity. 

As  COA  Sketch  continued  to  mature,  more  emphasis  was  placed  on  developing  the  underlying 
data  model  and  architecture.  Information  Operations  Planning  Capability  -  Experiment 
(lOPC-X)  was  a  risk  reduction  effort  to  develop  a  net-centric  data  strategy  and  architecture. 
lOPC-X  evolved  to  the  JFCOM  sponsored  VisIOn  program  and  simultaneously  was  soliciting 
capabilities  to  plug  into  the  future  architecture.  COA  Sketch  met  the  desired  operational  strategy 
plarming  requirements  and  was  transitioned. 

Maturation  of  COA  Sketch  and  lOPC-X  required  access  to  operationally-relevant,  planning 
mission  data  sources  such  as  MIDB,  JTT  and  FrOB.  The  External  Interfaces  task  explored 
cormection  to  these  databases. 

Collaboration  in  the  AOC  Context  focused  on  supporting  the  Strategy  Division  through 
improved  human-machine  and  human-human  information  exchanges.  Specifically,  the  tested 
capability,  LiveSpaces,  supports  Intense  Collaboration  (the  type  often  found  in  Command  and 
Control  environments).  The  final  event  for  SPVT  included  application  of  LiveSpaces  during  the 
TTCP  C3I  TP2  Distributed  Workshop,  in  which  representatives  from  three  countries  engaged  in 
collaboration  activities. 

The  Human  Effectiveness  in  the  Air  &  Space  Operations  Center  program  addressed  warfighter 
work  challenges  through  decision-centered  visualization  support  to  the  AOC  Strategy  Division. 
The  program  started  with  developing  a  thorough  understanding  of  the  warfighter  information  and 
decision  support  requirements,  individual,  machine  and  team  interactions.  A  strong  initial 
cognitive  work  analysis  set  the  foundation  for  subsequent  program  activities,  a  series  of  decision 
support  visualization  concepts  with  increasing  capability  and  fidelity.  The  effort  sponsored  by 
the  AFRL  711  Human  Performance  Wing/Human  Effectiveness  Directorate  yielded  an  extensive 
body  of  knowledge  for  the  AOC  SD,  numerous  concepts  available  to  other  USAF  and  Joint 
programs,  and  resulted  in  three  transitioned  products,  one  to  the  ESC  IWPC  program,  the 
USSTRATCOM  ISPAN  program,  and  one  to  the  JFCOM  VisIOn  program. 
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APPENDIX  A  -  SPVT  REQUIREMENTS 


The  following  503  AOC  operational  requirements  were  generated  during  the  SPVT  for  the  AOC 
program.  This  list  of  requirements  is  organized  chronologically  by  task  or  event  (JAST,  CEP, 
WAW,  COA  Sketch  and  high-level  COA  Sketch).  This  effort  provided  an  enterprise  level  view 
of  the  AOC,  AOC  personnel,  processes  and  information  flow  and  exchange  requirements.  The 
effort  ensured  traceability  to  all  sources  for  future  validation  and  clarification  of  need. 

Initial  understanding  of  AOC  high  level  needs  were  taken  from  the  ManTech  AOC  Cognitive 
Work  Analysis  (CWA)  generated  in  Phase  I  (prior  to,  but  overlapping  the  SPVT  contract).  The 
SPVT  project  built  upon  the  CWA  analysis  via  a  thorough  modeling  of  the  AOC  Strategy 
Division  processes.  The  analysis  included  a  literature  review  of  Air  Force  doctrine,  pamphlets 
and  other  materials  as  well  as  interviews  with  current  and  retired  warfighters  and  subject  matter 
experts  (SMEs). 

Initial  requirements  were  used  as  a  baseline  set  for  all  future  SPVT  efforts  to  provide  a  solid 
understanding  of  the  doctrinal  point  of  view  of  the  AOC  and  SPT  to  the  SRA  SPVT  project 
team.  Each  subsequent  task  built  on  the  requirements  foundation.  The  analysis  was  particularly 
useful  to  members  of  the  SRA  elicitation  teams  when  performing  CTA  interviews  of  SMEs. 
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SPVT  for  the  AOC  Requirements  Analysis 


JAST  Requirements  (303)  -  August  2005 

No. 

Requirement 

1 

Strategy  Planning  Capability  shall  reflect  status  on  the  JAOP  based  upon  identified 
changes/additions/removal  of  MOE 

2 

Strategy  Planning  Capability  shall  reflect  status  on  the  JAOP  based  upon  identified 
changes/additions/removal  of  MOP 

3 

Strategy  Planning  Capability  Shall  reflect  status  on  changes(additions/removals)  in  effects 
listed  within  the  JAOP 

4 

Strategy  Planning  Capability  shall  reflect  status  on  the  JAOP  based  upon  assumptions  of 
adversary's  most  likely  and  potentially  dangerous  COAs. 

5 

Strategy  Planning  Capability  shall  provide  status  on  the  start  and  end  time  of  operations 

6 

Strategy  Planning  Capability  shall  reflect  status  of  the  JAOP  due  to  new/change/removal  of 

EEls 

7 

Strategy  Planning  Capability  shall  reflect  status  of  AOD  based  upon  changes  in  timeframe 
listed  within  the  AOD 

8 

Strategy  Planning  Capability  shall  reflect  status  due  to  BNDRY  line  and  FSCL  changes  and 
timing 

9 

Strategy  Planning  Capability  shall  have  the  ability  to  relay  and  interpret  JFLCC  requests  for 
air,  space,  and  10  support. 

10 

Strategy  Planning  Capability  shall  have  the  ability  to  provide  feedback  on  air  operations  to  the 
JFLCC. 

11 

Strategy  Planning  Capability  shall  have  the  ability  to  ensure  the  new  Tgt  does  not  have  any 
excessive  CD  issues. 

12 

Strategy  Planning  Capability  shall  reflect  status  due  to  threats 

13 

Strategy  Planning  Capability  shall  indicate  status  of  support  elements  from  outside  the  air 
component 

14 

Strategy  Planning  Capability  shall  reflect  status  upon  the  JAOP  due  to  changes  in  Coalition 
unity 

15 

Strategy  Planning  Capability  shall  reflect  status  on  the  JAOP  based  identified  changes  of 
elements  in  the  enemy  system 

16 

Strategy  Planning  Capability  shall  reflect  status  upon  the  JAOP  when  an 
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advantage/disadvantage  of  the  selected  COA  comes  to  realization 

17 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  pre¬ 
planned  and  immediate  tasking  becoming  attainable 

18 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to 
dissemination  of  CEASE  BUZZER/CEASE  MUSIC  Calls  to  all  airborne  EA  assets 

19 

Strategy  Planning  Capability  shall  reflect  status  on  Operational  Tasks  pertaining  to  the  re-role 
of  AI/ATK  missions  to  CAS 

20 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to 
dissemination  of  NO  JAM  request  to  all  EA  units 

21 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to 

ATO/ACO  changes  input  into  daily  log  using  ATO/ACO. 

22 

Strategy  Planning  Capability  shall  reflect  status  on  Operational  Tasks  concerned  with  the 
ability  to  remain  in  close  contact  with  the  ASOC 

23 

Strategy  Planning  Capability  shall  reflect  status  due  to  defensive  CAP  manning  and  position 
changes 

24 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  WOCs 
coordinated  changes  with  the  JAOC 

25 

Strategy  Planning  Capability  shall  reflect  status  upon  the  STO/CW  COAs  that  directly  support 
the  operation  objectives  defined  in  the  JAOP 

26 

Strategy  Planning  Capability  shall  reflect  status  change  onto  the  JAOP  based  upon  STO/CW 
development  and  implementation 

27 

Strategy  Planning  Capability  shall  reflect  status  on  the  AOD  based  upon  TETT  Input 

28 

Strategy  Planning  Capability  shall  reflect  status  on  changes  in  apportionment 

29 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  analyze  data  from  NRT  tactical 
feeds  and  ISRD  MEC  counterparts  to  define  and  display  the  current  enemy  picture  in  NRT 

30 

Strategy  Planning  Capability  shall  have  the  ability  to  integrate  naval  air,  naval  fires,  and 
amphibious  operations  into  theater  air  operations  and  monitor  and  interpret  the  maritime  battle 
situation  for  the  JAOC 

31 

strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  maintain  real  time  mission 
support  coordination  with  the  JSOACC 

32 

Strategy  Planning  Capability  shall  reflect  status  due  to  external  COP  architecture  requirements 

33 

Strategy  Planning  Capability  shall  reflect  status  due  to  GCCS/SAA  COP  CST  connections 
between  nodes  and  the  UB  configuration 
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34 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  provide  feedback  on  status  of 
dynamic  and  ad  hoc  CR. 

35 

Strategy  Planning  Capability  shall  reflect  status  due  to  Requirement 

36 

Strategy  Planning  Capability  shall  indicate  when  and  if  the  AOD  Breakout  meeting  with  TETT 
has/will  take  place 

37 

Strategy  Planning  Capability  shall  reflect  status  due  to  ensure  sufficient  internal  Unified  Build 
(UB)  masters,  processors,  and  clients  are  planned  to  support  the  JAOC  requirements  while 
allowing  support  to  subordinate  UB  masters 

38 

Strategy  Planning  Capability  shall  reflect  status  due  to  risks  related  to  prevention  of  fratricide 

39 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  coordinate  with  subordinate 
units  of  the  TACS  and  PEDs  /ISR  architecture. 

40 

Strategy  Planning  Capability  shall  Coordinate  Airspace  requirements. 

41 

Strategy  Planning  Capability  Shall  reflect  status  change  based  on  MARLO  integration  into  the 
JAOP 

42 

Strategy  Planning  Capability  shall  have  the  ability  to  monitor  recovery  efforts;  to  plan, 
coordinate,  and  execute  joint  search  and  rescue  (SAR)  and  CSAR  operations:  and  to  integrate 
CSAR  operations  with  other  evasion,  escape,  and  recovery  operations  within  the  geographical 
area  assigned  to  the  joint  force 

43 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  coordinate  with  the 

RCC/JSRC 

44 

Strategy  Planning  Capability  shall  have  the  ability  to  coordinate  with  users,  workgroup 
managers,  and  CFP  personnel  to  resolve  computer  software  and  hardware  problems. 

45 

strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  coordinate  operational  and 
intelligence  inputs  from  the  JSOACC  into  the  Tgt  process 

46 

Strategy  Planning  Capability  shall  reflect  status  due  to  the  ability  to  execute  the  RSTA  Annex 
and  the  ATO. 

47 

Strategy  Planning  Capability  shall  have  the  ability  to  manage  user  computer  software 
configurations  and  tactical  LAN  systems. 

48 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  maintain  a  close  and 
continuous  flow  of  information  between  themselves  and  ISRD  intelligence  analysts  to  ensure  a 
common  view  of  the  battlespace  and  consistent  threat  presentation  is  provided  to  the  JAOC 
and  tactical  units. 

49 

Strategy  Planning  Capability  shall  reflect  status  due  to  proper  computer  information  pipeline 
requirements  (NIPRNeT,  SIPRNeT,  EMAIL,  COALITION  LAN,  TBMCS,  etc.); 

50 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  overcome  language  barriers 
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with  remote  allied/coalition  forces 

51 

Strategy  Planning  Capability  shall  have  the  ability  to  resolve  problems  and  to  maintain  efficient 
operation  of  the  TBMCS  network. 

52 

Strategy  Planning  Capability  shall  reflect  status  due  to  TBMCS  network  status  and  limitations. 

53 

Strategy  Planning  Capability  shall  have  the  ability  to  manage  the  installation  and  operation  of 
TBMCS  equipment  and  its  network. 

54 

Strategy  Planning  Capability  shall  reflect  status  due  to  JAOC  network  requirements 

55 

Strategy  Planning  Capability  shall  Receive  a  copy  of  MARFOR  aviation  decision  support 
products  from  the  MAW  TACC  current  ops  to  assist  in  monitoring  the  MARFOR  plan. 

56 

Strategy  Planning  Capability  shall  reflect  status  due  to  WOCs  changes  to  scheduled  missions, 
refueling,  SCLs,  etc. 

57 

Strategy  Planning  Capability  shall  reflect  status  upon  the  AOD  due  to  evaluation  of  related 
MOEs 

58 

Strategy  Planning  Capability  shall  indicate  completion  status  of  steps/tasks  within  the  JAEP 
process 

59 

Strategy  Planning  Capability  shall  reflect  status  on  the  fulfillment  of  Essential  Elements  of 
Information(EEIs) 

60 

strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to 
dynamically  adjusting  ISR  assets 

61 

Strategy  Planning  Capability  shall  reflect  status  due  to  availability  of  collected  data  for  mission 
analysis. 

62 

Strategy  Planning  Capability  shall  reflect  status  upon  the  evaluation  of  tactical  engagement 
results  and  effects 

63 

Strategy  Planning  Capability  shall  reflect  status  upon  the  AOD  due  to  a  change  or  addition  of 
an  operational  or  tactical  air  objective 

64 

Strategy  Planning  Capability  shall  reflect  status  on  to  the  JAOP  due  to  changes  in  desired  end 
state 

65 

Strategy  Planning  Capability  shall  reflect  status  on  re-attack  decisions  in  the  JAOP 

66 

Strategy  Planning  Capability  shall  reflect  status  upon  desired  effects  identified  in  the  JAOP 

67 

Strategy  Planning  Capability  shall  indicate  changes  within  other  components  plans  to  ensure 
smooth  coordination  of  air,  space,  and  surface  operations. 

68 

Strategy  Planning  Capability  shall  reflect  status  of  the  expected  collateral  damage  of  targets 
listed  within  the  JAOP 
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69 

Strategy  Planning  Capability  shall  reflect  status  on  the  JAOP  based  upon  LOE  status  against 
targets 

70 

Strategy  Planning  Capability  shall  reflect  status  on  the  JAOP  by  tracking  phasing 

71 

Strategy  Planning  Capability  shall  reflect  status  on  changes  in  legality,  political,  and  moral 
constraints  factors  in  the  JAOP 

72 

Strategy  Planning  Capability  shall  reflect  status  changes  in  the  JAOP  based  upon  logistics 

73 

Strategy  Planning  Capability  shall  reflect  status  to  changes  in  sequence  related  to  critical 
tasks  listed  in  the  AOD 

74 

Strategy  Planning  Capability  shall  reflect  status  due  to  ground  situation 

75 

Strategy  Planning  Capability  shall  reflect  status  due  to  ATO  sortie  execution 

76 

Strategy  Planning  Capability  shall  reflect  status  due  to  dynamic  adjustments/changes  to  the 
RSTA  Annex 

77 

Strategy  Planning  Capability  shall  reflect  status  due  to  Tgt  changes  within  the  ATO  cycle 

78 

Strategy  Planning  Capability  shall  reflect  status  on  the  JAOP  due  to  effects  assessment 
considerations 

79 

Strategy  Planning  Capability  shall  reflect  status  upon  the  confidence  levels  assigned  to 
assessment  of  the  status  of  operational  air  objectives  included  in  the  JAOP/AOD 

80 

Strategy  Planning  Capability  shall  provide  status  upon  time  constraints  based  upon  Mission 
Guidance 

81 

Strategy  Planning  Capability  shall  reflect  status  upon  the  JAOP  due  to  location  of  conflict 

82 

Strategy  Planning  Capability  shall  reflect  status  upon  measures  and  indicators  identified  in  the 
JAOP 

83 

Strategy  Planning  Capability  shall  reflect  changes  in  force  availability,  tinning,  bed  down  and 
sustainment  requirements 

84 

strategy  Planning  Capability  shall  reflect  status  in  change  in  the  Ends,  Means,  Ways,  and  Risk 
associated  with  the  selected  COA 

85 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to 
immediate  EW  requests  from  Air  Force,  joint,  or  combined  forces;  coordinated  with  the  Army 
BCD  and  joint  Service  LNOs  for  support  requests. 

86 

Strategy  Planning  Capability  shall  reflect  status  upon  a  prioritized  AOD  task  by  tracking  the 
status  of  the  linked  nominated  Tgt 

87 

Strategy  Planning  Capability  shall  reflect  status  on  the  priority  of  Tgt  linked  to  associated 
prioritized  tasks  outlined  in  the  AOD 
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88 

Strategy  Planning  Capability  shall  reflect  status  based  on  changes  to  the  Tgt  plan  that  will 
effect  the  AOD 

89 

Strategy  Planning  Capability  shall  reflect  status  of  AOD  based  upon  changes  in  effects  listed 
within  the  AOD 

90 

Strategy  Planning  Capability  shall  have  the  ability  to  receive  requests  from  the  MAW  TACC 
current  ops  for  additional  joint  sorties 

91 

Strategy  Planning  Capability  shall  reflect  status  due  to  Tgt  re-nomination  identified  to  the  CPD 
MAAP  Team  for  potential  sourcing  on  the  next  ATO. 

92 

strategy  Planning  Capability  shall  reflect  status  due  to  operational  effects  of  recommended 
changes  when  supporting  dynamic  Tgt/TSTs. 

93 

Strategy  Planning  Capability  shall  reflect  status  due  to  near  term  and  future  ATO  re-strike 
recommendations  provided  by  the  ISRD  Tgt/CA  Team  via  MISREP 

94 

Strategy  Planning  Capability  shall  reflect  status  due  to  JFC  campaign  plan  and  component 
plans. 

95 

Strategy  Planning  Capability  shall  provide  status  changes  based  upon  location  changes  of 
action(s) 

96 

Strategy  Planning  Capability  shall  reflect  status  upon  JAOP  changes  due  to  Combat  Support 
factors 

97 

Strategy  Planning  Capability  shall  provide  indications  of  fulfillment  of  CCIRS 

98 

strategy  Planning  Capability  shall  reflect  status  on  completion  on  collection  plan  for  Area  of 
Interest 

99 

Strategy  Planning  Capability  shall  reflect  status  upon  measures  of  merit  (MOMs)  identified  in 
the  JAOP 

100 

Strategy  Planning  Capability  shall  reflect  status  upon  target  sets  identified  in  the  JAOP 

101 

Strategy  Planning  Capability  shall  reflect  status  upon  perishable  TST  in  the  JAOP 

102 

Strategy  Planning  Capability  shall  provide  status  on  changes  in  "acceptable  risk"  of  the 
Commander's  Intent 

103 

Strategy  Planning  Capability  shall  reflect  status  onto  JAOP  changes  based  upon  indications  of 
incorrect  Assumptions  considered  estimation  process 

104 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  real-time 
changes  to  the  ATO,  including  responding  to  emergency  AR,  CSAR,  TST,  CASREQ  etc. 

105 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  frequency 
deconfliction  issues  with  Frequency/Spectrum  Manager,  EWCC,  BCD,  and  other  applicable 
agencies 
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106 

Strategy  Planning  Capability  shall  inform  user  when  Tgt  in  TNL  correlating  back  to  the  AOD 
are  imported  into  an  ATO 

107 

Strategy  Planning  Capability  shall  reflect  status  on  to  the  JAOP  due  to  disparities  occurring 
between  actual  and  expected  results  of  an  operational  air  objective 

108 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  ensure  deconfliction  and 
tasking  of  space  assets 

109 

Strategy  Planning  Capability  shall  provide  status  on  changes  (additions/removals)  to  possible 
COAs  during  the  JAEP  process 

110 

Strategy  Planning  Capability  shall  have  the  ability  for  BCD  to  coordinate  ground  force 
priorities,  requests,  and  items  of  interest 

111 

Strategy  Planning  Capability  shall  have  the  ability  to  coordinate  and  obtain  results  of  flying 
operations  from  other  agencies  within  the  JAOC 

112 

strategy  Planning  Capability  shall  reflect  status  due  to  Tgt  being  re-nominated 

113 

Strategy  Planning  Capability  shall  reflect  status  due  to  diverts/aborts  of  C2  aircraft 

114 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  pass  C2  assets  contact/Tgt 
information. 

115 

Strategy  Planning  Capability  shall  reflect  changes  in  the  JAOP  due  to  ID  of  key  decision  points 
and  events 

116 

Strategy  Planning  Capability  shall  provide  status  on  changes  in  Reason  within  the  Mission 
Statement 

117 

Strategy  Planning  Capability  shall  reflect  status  upon  the  JAOP  changes  based  upon  area 

ADP  (AADP) 

118 

Strategy  Planning  Capability  shall  reflect  status  on  changes  in  TPFDD  requirements 

119 

Strategy  Planning  Capability  shall  reflect  status  on  change  in  C2  relationships  of  assigned, 
attached,  transient  and  available  forces 

120 

Strategy  Planning  Capability  shall  reflect  status  upon  the  JAOP  based  upon  air  and  space 
power  changes  due  to  unforeseen  limitations  and  capabilities 

121 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  ODO's 
Receipt  of  Dynamic  Tgt  information  and  priorities/targeting  for  planned  ATO  missions  when 
the  situation  warrants 

122 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to 
immediate  electronic  support  requests 

123 

Strategy  Planning  Capability  shall  reflect  status  as  to  whether  the  JIPTL  representing  Tgt  from 
the  AOD  has  been  approved  by  the  JFACC/JFC 
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124 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  coordinate  theater  space 
support  requests  to  reachback  organizations  as  required 

125 

Strategy  Planning  Capability  shall  reflect  status  due  to  Validate  and  distribute  ATO  change 
messages 

126 

Strategy  Planning  Capability  shall  reflect  status  due  to  effective  recommendations  for  WTP 

127 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  F2T2 

128 

Strategy  Planning  Capability  shall  have  the  ability  to  maintain  total  awareness  on  the  battle 
situation  and  unit's  status. 

129 

Strategy  Planning  Capability  shall  reflect  status  of  JTCB  changes  to  nominated  Tgt  listed 
within  the  AOD 

130 

Strategy  Planning  Capability  shall  reflect  status  on  Tgt  imported  into  the  ATO  that  correlate 
back  to  the  AOD 

131 

Strategy  Planning  Capability  shall  reflect  status  due  to  Input  ATO  changes  into  TBMCS. 

132 

Strategy  Planning  Capability  shall  reflect  status  due  to  changes  to  leaflet  and  PSYOP 
broadcast  missions 

133 

Strategy  Planning  Capability  shall  have  the  ability  to  pass  on  critical  information  to/from  their 
respective  WOC  concerning  air  raid  warnings,  unexpected  changes,  diverting  aircraft,  and 
airfield  status. 

134 

Strategy  Planning  Capability  shall  reflect  status  due  to  changes  in  employment  of  offensive 

WPN  systems. 

135 

Strategy  Planning  Capability  shall  reflect  status  onto  the  JAOP  based  on  changes  to  the 
strategy-to-task  matrix 

136 

Strategy  Planning  Capability  shall  reflect  status  upon  the  AOD  due  to  a  phase  shift  for  the 
component; 

137 

Strategy  Planning  Capability  shall  monitor  approaching  key  decision  points  within  the  JAOP 
and  the  selected  path  going  forward 

138 

Strategy  Planning  Capability  shall  reflect  status  for  Operational  Tasks  based  on  data  from  the 
CAS  cell  in  coordination  with  the  BCD 

139 

Strategy  Planning  Capability  shall  have  the  ability  to  Monitor  weather,  airfield  status,  support 
facilities,  etc. 

140 

Strategy  Planning  Capability  shall  reflect  status  due  to  mission  deviations  and  changes 

141 

strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  mission 
not  having  all  the  support  required 
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142 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  SODO 
adjustments  to  offensive  resources  to  ensure  mission  success 

143 

Strategy  Planning  Capability  shall  reflect  status  based  on  changes  to  JFC  and  JFACC 
guidance  into  the  JAOP 

144 

Strategy  Planning  Capability  shall  reflect  status  upon  Tgt  nominations  in  accordance  with  the 
AOD 

145 

Strategy  Planning  Capability  shall  have  the  ability  to  coordinate  the  real-time  employment  of 
all  10  assets,  except  for  EW,  assigned  or  made  available  to  the  JFACC. 

146 

strategy  Planning  Capability  shall  reflect  status  due  to  friendly  and  enemy  battlespace 
changes  that  affect  the  ISR  plan 

147 

Strategy  Planning  Capability  shall  have  the  ability  to  monitor  the  execution  of  the  ATO  for  the 
assigned  assets  they  represent 

148 

Strategy  Planning  Capability  shall  reflect  status  due  to  synchronize  and  deconflict  PSYOP  into 
the  air  and  space  campaign 

149 

Strategy  Planning  Capability  shall  reflect  status  due  to  Exchange  Operational  and  Intelligence 
data. 

150 

Strategy  Planning  Capability  shall  reflect  status  due  to  significant  changes  in  the  EOB 

151 

strategy  Planning  Capability  shall  reflect  status  on  Tgt  plan  based  on  the  correlation  of  the 
plan  to  the  guidance  used  in  the  AOD 

152 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  find  a  strike  package  able  to 
prosecute  the  Tgt 

153 

Strategy  Planning  Capability  shall  have  the  ability  to  monitor  Dynamic  Tgt  management  using 
an  automated  tool  such  as  ADOCS  ITM  or  like  systems  and  other  CT 

154 

Strategy  Planning  Capability  shall  have  the  ability  to  ensure  each  mission  has  all  the  support 
available  and  that  each  tasking  reflects  an  effective  and  tactically  prudent  us  of  that  asset. 

155 

Strategy  Planning  Capability  shall  reflect  status  due  to  airspace  changes/additions 

156 

Strategy  Planning  Capability  shall  reflect  status  on  change  in  JAOP's  JFACC  objectives  due  to 
evaluation  of  overall  theater  campaign  plan 

157 

Strategy  Planning  Capability  shall  reflect  status  upon  tactical  engagements  identified  in  the 

AOD 

158 

Strategy  Planning  Capability  shall  provide  status  on  the  status  of  JFACC  approval  of  Mission 
Statement 

159 

Strategy  Planning  Capability  shall  reflect  status  upon  JAOP  changes  based  upon  Operation 

Risk  Analysis  factors 
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160 

Strategy  Planning  Capability  shall  reflect  status  onto  JAOP  changes  based  upon  changes  in 
credibility  of  facts  considered  during  COA  analysis 

161 

Strategy  Planning  Capability  shall  reflect  change  of  status  on  the  JAOP  due  to  changes  in 
force  protection  requirements 

162 

Strategy  Planning  Capability  shall  reflect  status  upon  the  JAOP  due  to  Information  and  Space 
Operations  changes 

163 

Strategy  Planning  Capability  shall  show  status  of  usage  of  excess  sortie  generation  capability 
(airman  *reserve*  sorties) 

164 

Strategy  Planning  Capability  shall  reflect  status  upon  the  JAOP  based  upon  the  ability  to 
integrate  with  the  capabilities  of  the  other  services,  nations  and  components  that  apply 
airpower 

165 

Strategy  Planning  Capability  shall  provide  status  on  effects  to  include  level  of  disruption, 
distribution  and  duration  of  the  effect 

166 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  changes 
in  the  ATO  for  EW  assets 

167 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  problems 
with  ASM  of  EW/SEAD  assets. 

168 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  required 
changes  to  the  ISR  plan  of  other  JAOC,  Component  and  CFC  intelligence  organizations 

169 

Strategy  Planning  Capability  shall  have  the  ability  to  coordinate  with  the  DTC 

170 

strategy  Planning  Capability  shall  provide  status  upon  the  JAOP/AOD  elements  due  to 
coordinated  mission  changes  from  the  ALDO  and  the  Airlift  Operations  Officer 

171 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to 
subordinate  TACS  elements,  through  their  respective  duty  officers,  assessments  of  EW/SEAD 
effectiveness 

172 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  aircrew 
availability,  airfield  status,  weather,  and  status  of  alert  jets  and  change  to  contingencies  plans 
as  determined  by  the  WOCS 

173 

Strategy  Planning  Capability  shall  have  the  ability  to  inform  WOCs  for  each  asset  of  changes 
in  the  ATO 

174 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  major 
changes  in  EW  asset  utilization,  availability,  or  other  significant  impacts  on  the  EW  mission 

areas 

175 

Strategy  Planning  Capability  shall  reflect  status  due  to  changes  in  ALDO  monitored  inter-  and 
intra-theater  air  movement. 
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176 

Strategy  Planning  Capability  shall  reflect  status  on  the  AOD  based  upon  JIPTL  non- 
compliance 

177 

Strategy  Planning  Capability  shall  provide  status  as  to  how  component's  requirements  within 
the  AOD  have  been  met  through  the  Tgt  plan 

178 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  integrate  national,  space- 
based  and  theater  assets  into  PR  execution. 

179 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  collect  and  exploit  required 
MASINT 

180 

Strategy  Planning  Capability  shall  reflect  status  due  to  changes  in  tasking  or  requests  for 
additional  MAW  fighter  sorties  to  the  MAW  TACC  current  ops. 

181 

Strategy  Planning  Capability  shall  reflect  status  due  to  tactics  changes  affecting  air  and  space 
operations 

182 

Strategy  Planning  Capability  shall  have  the  ability  to  ensure  that  all  SOF  Tgt,  SOF  teams,  and 
SOF  air  taskings/missions  are  deconflicted,  properly  integrated,  and  coordinated  during  all 
planning  and  execution  phases 

183 

strategy  Planning  Capability  shall  Accept  immediate  airspace  control  means  requests 
(ACMREQ),  enter  the  information  in  the  AD  module  of  TBMCS,  and  conduct  deconfliction  as 
required 

184 

Strategy  Planning  Capability  shall  reflect  status  due  to  changes  in  airspace  for  C2  assets  for 
TLAM  launches 

185 

Strategy  Planning  Capability  shall  reflect  status  due  to  changes  in  status  of  ATO  assigned 
assets  that  impact  ATK  coordinator/SODO/SADO  operations 

186 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  delegate  air  defense 
responsibilities  to  subordinate  TACS  units 

187 

Strategy  Planning  Capability  shall  reflect  status  on  the  JAOP  due  to  OAT  recommendations 
for  branch/sequel  planning  considerations 

188 

strategy  Planning  Capability  shall  reflect  status  onto  the  JAOP  due  to  evaluation  of  collection 
strategies 

189 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to 
immediate  SEAD  requests  from  Air  Force,  joint  or  combined  forces;  coordinated  with  the  BCD 
and  joint  service  LNO  for  support  requests. 

190 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  SODO's 
prosecuting  personnel  recovery  missions  using  the  dynamic  Tgt  process,  providing  the 
firepower  and  suppression  necessary  for  mission  success. 

191 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  SODO's 
approved  changes  to  the  ATO 
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192 

Strategy  Planning  Capability  shall  reflect  changes  in  status  to  the  JAOP/AOD  due  to  base 
capabilities 

193 

Strategy  Planning  Capability  shall  reflect  JFACC  approval  of  the  ATO  in  reflection  of  Tgt  listed 
in  the  ATO  that  reflect  the  AOD 

194 

Strategy  Planning  Capability  shall  reflect  status  changes  to  the  AOD  based  upon  changes 
brought  up  during  the  JFACC  Strategy  Update  Briefing 

195 

Strategy  Planning  Capability  shall  provide  status  on  responsible  party  ensuring  AOD  guidance 
to  ISRD  Tgt  Development  Cell  targeteers 

196 

Strategy  Planning  Capability  shall  reflect  status  due  to  Tgt  ability  to  collect  CD  and  fratricide 
assessments  for  assigned  targets. 

197 

Strategy  Planning  Capability  shall  reflect  status  due  to  adjustments  and  improvements  in 
airspace  control  procedures. 

198 

Strategy  Planning  Capability  shall  maintain  current  status  of  the  GPS  constellation  and 
impacts  to  theater  operations 

199 

Strategy  Planning  Capability  shall  have  the  ability  to  raise  JFACC  concerns  or  PSYOP 
objective/tasking  to  the  JFC  for  consideration,  planning,  and  execution. 

200 

strategy  Planning  Capability  shall  reflect  status  due  to  SEAD 

201 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  coordinate  airspace 
deconfliction  Joint  Special  Operations  Air  Component  Commander  (JSOACC) 

202 

Strategy  Planning  Capability  shall  have  the  ability  to  coordinate  Airlift  support  for  JFACC 
operations. 

203 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  monitor  and  rapidly  adjust  ISR 
platforms/sensors,  collection  tracks,  and  associated  PED  nodes  in  response  to  emerging 
threats/Tgt,  environmental  factors,  changes  in  mission  priorities,  and/or  operational  changes. 

204 

Strategy  Planning  Capability  shall  reflect  status  due  to  EW/SEAD  Tgt  issues 

205 

Strategy  Planning  Capability  shall  reflect  status  due  to  a  WPN  platform  being  diverted  from  its 
original  Tgt 

206 

Strategy  Planning  Capability  shall  reflect  status  due  to  space  environmental  impacts 

207 

Strategy  Planning  Capability  shall  reflect  status  due  to  what  support  is  available  at  divert  fields 

208 

Strategy  Planning  Capability  shall  reflect  status  due  to  C2  issues 

209 

Strategy  Planning  Capability  shall  reflect  status  due  to  communication  issues 

210 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  advise  C2  assets  when  aircraft 
under  their  control  have  been  tasked/retasked 
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211 

Strategy  Planning  Capability  shall  reflect  status  on  changes  of  world  opinion 

212 

Strategy  Planning  Capability  shall  reflect  status  upon  the  JAOP  due  to  adversary's  use  of 

WMD 

213 

Strategy  Planning  Capability  shall  reflect  status  due  to  status  of  divert  airfields 

214 

Strategy  Planning  Capability  shall  reflect  status  on  the  AOD  due  to  priority  shifts 

215 

Strategy  Planning  Capability  shall  reflect  status  on  the  AOD  due  to  changes  in  environmental 
factors 

216 

Strategy  Planning  Capability  shall  reflect  status  change  to  the  plan  based  upon  Combat 
support  considerations 

217 

Strategy  Planning  Capability  shall  reflect  status  upon  the  JAOP/AOD  due  to  changes  after  PIR 
review  of  JFACC  guidance 

218 

Strategy  Planning  Capability  shall  reflect  status  of  Tgt  listed  in  AOD  after  action  has  been 
taken  against  them 

219 

Strategy  Planning  Capability  shall  reflect  status  on  the  AOD/JAOP  due  to  changes  in  the  IPB 

220 

Strategy  Planning  Capability  shall  reflect  status  on  the  AOD  due  to  changes  in  MOEs. 

221 

Strategy  Planning  Capability  shall  reflect  status  on  the  AOD  due  to  changes  in  JFACC 
objectives 

222 

Strategy  Planning  Capability  shall  reflect  status  of  deficiencies/inadequacies  in  intelligence 
support  that  is  used  in  the  AOD/JAOP 

223 

Strategy  Planning  Capability  shall  reflect  status  on  the  AOD  due  to  changes  in  the  JIPTL 

224 

Strategy  Planning  Capability  shall  reflect  status  on  the  AOD  with  respect  to  the  changes  in 
predicted  adversary  activity  in  the  battlespace 

225 

Strategy  Planning  Capability  shall  reflect  status  upon  Tgt  listed  in  the  AOD  based  upon  TST 
and  dynamic  targeting  situations 

226 

Strategy  Planning  Capability  shall  reflect  changes  due  to  COA  comparison  factors/elements 

227 

Strategy  Planning  Capability  shall  reflect  status  of  inefficiencies  noted 

228 

strategy  Planning  Capability  shall  reflect  status  of  last  minute  ATO  changes  due  to  Review 

229 

Strategy  Planning  Capability  shall  reflect  status  of  enemy  attack 

230 

Strategy  Planning  Capability  shall  reflect  status  of  ATO  flow  change  due  to  offensive  and 
defensive  air-to-air  battlespace  situation. 

231 

Strategy  Planning  Capability  shall  reflect  status  of  required  support 
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232 

Strategy  Planning  Capability  Shall  reflect  status  upon  problems  enforcing  positive  control 
measures 

233 

Strategy  Planning  Capability  shall  reflect  status  upon  problems  due  to  computer  and 
communications  failure 

234 

Strategy  Planning  Capability  shall  reflect  status  of  deviations  in  the  ATO 

235 

Strategy  Planning  Capability  shall  reflect  status  due  to  issues  or  changes  with  Command  and 
Control(C2)  assets 

236 

Strategy  Planning  Capability  shall  reflect  status  upon  the  AOD's  prioritized  task  against  the  Tgt 
list 

237 

Strategy  Planning  Capability  shall  reflect  status  due  to  re-role,  diverts,  TST  missions 
information  changes 

238 

Strategy  Planning  Capability  shall  reflect  status  due  to  ATACMS  airspace  issues 

239 

Strategy  Planning  Capability  shall  reflect  status  due  to  changes  made  to  plan  recommended  to 
the  SADO 

240 

Strategy  Planning  Capability  shall  reflect  status  due  to  information  gathered  during 
INLFIGHTREP 

241 

Strategy  Planning  Capability  shall  reflect  status  due  to  changes  in  overall  employment  of  air 
defense  WPN  systems. 

242 

Strategy  Planning  Capability  shall  reflect  status  due  to  the  ability  to  assess  available  fighter 
and  air  defense  missile  assets 

243 

Strategy  Planning  Capability  shall  reflect  status  due  to  International  airspace  issues 

244 

Strategy  Planning  Capability  shall  reflect  changes  due  to  status  of  offensive  assets 

245 

Strategy  Planning  Capability  shall  reflect  status  due  to  condition  and  status  of  patriot  battery 

246 

Strategy  Planning  Capability  shall  reflect  status  on  the  impact  of  space  forces  on  theater  air 
operations. 

247 

Strategy  Planning  Capability  shall  reflect  status  due  to  deployment  of  air  assets,  ground  alert 
and  airborne,  for  SCUD  missions. 

248 

Strategy  Planning  Capability  shall  refelct  status  on  the  ability  to  manage  theater  digital  data 
link  interface  systems  and  other  automated  air  displays. 

249 

Strategy  Planning  Capability  shall  reflect  status  on  ability  to  administer  C2  systems  operating 
systems. 

250 

Strategy  Planning  Capability  shall  reflect  status  due  to  changes  in  predicted  enemy  COA. 
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251 

Strategy  Planning  Capability  shall  reflect  status  on  ability  to  setup  and  maintain  C2  systems 
servers. 

252 

Strategy  Planning  Capability  shall  reflect  status  due  to  impending  enemy  ATK 

253 

Strategy  Planning  Capability  shall  reflect  status  due  to  changes  in  Ground/Air  Control 
Measures(ACM)  and  Fire  Support  Coordination  Measures  (FSCM) 

254 

Strategy  Planning  Capability  shall  reflect  weather  effects  on  operations  as  directed  by  the 

CCO. 

255 

Strategy  Planning  Capability  shall  reflect  status  due  to  abillity  to  advise  Battle  Coordination 
Detachment(BCD)  when  clear  to  fire 

256 

Strategy  Planning  Capability  shall  reflect  status  due  to  the  ability  to  correlate  the  ATO  to  the 
air  picture  being  displayed  on  the  GCCS. 

257 

Strategy  Planning  Capability  shall  reflect  status  due  to  the  ability  to  ensure  accurate  display  of 
Common  Operating  Picture(COP)  on  the  Combat  Operations  floor. 

258 

Strategy  Planning  Capability  shall  reflect  status  on  the  ability  to  provide  support  through 
ground  maneuver. 

259 

Strategy  Planning  Capability  shall  reflect  status  due  to  implementation  of  required  changes  to 
data  filtering  approved  by  the  Joint  Interface  Control  Officer  (JICO) 

260 

Strategy  Planning  Capability  shall  reflect  status  due  to  significant  Combat  Operations  issues 
logged  for  debrief  to  units/Combat  Plans 

261 

Strategy  Planning  Capability  shall  reflect  situational  awareness  of  locations. 

262 

strategy  Planning  Capability  shall  reflect  status  on  the  ability  to  deconflict  real-time,  areas  of 
surveillance  responsibility. 

263 

Strategy  Planning  Capability  shall  reflect  status  due  to  Defensive  Counter  Air(DCA)/Offensive 
Counter  Air(OCA)  issues 

264 

Strategy  Planning  Capability  shall  reflect  status  on  availability  of  munition  types  to  apply 
against  Tgt,  taking  into  account  collateral  damage  concerns. 

265 

Strategy  Planning  Capability  shall  reflect  status  due  to  inappropriate  Standard  Conventional 
Loads(SCLs),  inadequate  tanker  offloads 

266 

Strategy  Planning  Capability  shall  reflect  status  on  the  ability  to  coordinate  changes  to  C2 
systems  through  the  CFP. 

267 

Strategy  Planning  Capability  shall  reflect  status  due  to  how  Air  Defense  Combat  Air  Patrol 
(CAP)  management  problems/impacts  to  air  operations. 

268 

Strategy  Planning  Capability  shall  reflect  status  due  to  brevity  code  word  changes 
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269 

Strategy  Planning  Capability  shall  reflect  status  due  to  joint  weapon  capabilities 

270 

Strategy  Planning  Capability  shall  reflect  target  status. 

271 

Strategy  Planning  Capability  shall  reflect  status  on  all  statuses  managed  by  Defensive  Duty 
Officers  (DDOs) 

272 

Strategy  Planning  Capability  shall  reflect  status  due  to  the  abilities  to  accommodate  specific 
aircraft  missions  (AWACS,  DCA,  F-15,  etc.). 

273 

Strategy  Planning  Capability  shall  reflect  status  due  to  tanker  issues 

274 

Strategy  Planning  Capability  shall  reflect  status  due  to  execution/notification  of  TBM  warning 

275 

Strategy  Planning  Capability  shall  reflect  status  due  to  the  ability  to  coordinate  units 
entering/exiting  the  interface. 

276 

Strategy  Planning  Capability  shall  reflect  status  due  to  the  ability  to  coordinate  changes  in 

Area  of  Responsibility(AOR)  for  surveillance  as  the  tactical  situation  dictates 

277 

Strategy  Planning  Capability  shall  reflect  status  due  to  ability  to  setup  and  maintain  C2  system 
workstation  hardware  in  a  timely  manner. 

278 

Strategy  Planning  Capability  shall  reflect  status  due  to  interface  anomalies  (i.e.  dual 
designations,  duplicate  tracks,  false  Tgt,  runway  tracks,  ID,  and  category  conflicts). 

279 

Strategy  Planning  Capability  shall  reflect  status  on  the  ability  to  coordinate  with  the  JSOTF 
and  JPOTF  LNO  for  employment  of  excess  JSOTF  PSYOP  assets. 

280 

Strategy  Planning  Capability  shall  reflect  status  on  the  ability  to  coordinate  space  FE  support 
for  theater  operations. 

281 

Strategy  Planning  Capability  shall  reflect  status  due  to  direct  engagement  of  identified  hostile 
surface  Targets. 

282 

Strategy  Planning  Capability  shall  reflect  statuses  through  the  use  of  TBMCS. 

283 

Strategy  Planning  Capability  shall  reflect  status  of  the  ability  to  display  and  maintain  air 
situational  data  and  update  air  base,  flight  facility,  and  TACS  status  as  required. 

284 

Strategy  Planning  Capability  shall  reflect  status  due  to  the  engagement  of  identified  hostile 
aircraft. 

285 

Strategy  Planning  Capability  shall  reflect  status  due  to  the  ability  to  maintain  intelligence  feeds 
(TIBS/TDDS)  flowing  via  ADSI. 

286 

Strategy  Planning  Capability  shall  reflect  status  due  to  defensive  operations  equipment 
problems/issues 

287 

Strategy  Planning  Capability  shall  reflect  status  due  to  diverts/aborts  of  DCA  aircraft 

288 

Strategy  Planning  Capability  shall  reflect  status  due  to  potential  deviations  from  the  ATO. 
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289 

Strategy  Planning  Capability  shall  reflect  status  due  to  the  ability  to  delegate  authorities  (ie. 
Border  crossing,  ID,  declaration  and  engagement  authorities,  to  subordinate  elements  of  the 
TAGS) 

290 

Strategy  Planning  Capability  shall  reflect  status  on  the  ability  to  perform  detection  and 
monitoring  of  critical  class  track  activity  and  emergency  situations,  as  well  as  defensive  and 
special  missions. 

291 

Strategy  Planning  Capability  shall  reflect  status  due  to  host  nation  defense/issues. 

292 

Strategy  Planning  Capability  shall  reflect  status  on  mission  details. 

293 

strategy  Planning  Capability  shall  reflect  status  upon  the  JAOP/AOD  due  to  unit  status  as 
provided  by  the  Operations  Duty  Officer 

294 

Strategy  Planning  Capability  shall  reflect  status  due  to  problems/impacts  to  air  operations  with 
regard  to  airborne  C2  support 

295 

Strategy  Planning  Capability  shall  reflect  status  on  guidance  governing  mission  support 
requirements 

296 

Strategy  Planning  Capability  shall  reflect  status  due  to  ATO  flow  correctly  mirroring  current  air 
situation  for  DCA/OCA  assets. 

297 

Strategy  Planning  Capability  shall  reflect  status  due  to  associated  MISREP  availability 

298 

Strategy  Planning  Capability  shall  reflect  status  due  to  changes  to  SPINS 

299 

Strategy  Planning  Capability  shall  reflect  status  due  to  significant  problems  or  limitation 
requiring  an  adjustment  to  operations. 

300 

Strategy  Planning  Capability  shall  reflect  status  on  the  ability  to  remain  current  on  the  air  and 
ground  situation 

301 

Strategy  Planning  Capability  shall  reflect  status  on  ability  to  prepare  materials  for  the  shift 
debriefs 

302 

Strategy  Planning  Capability  shall  reflect  status  on  the  ability  to  push  ATO  to  EMC 

303 

Strategy  Planning  Capability  shall  reflect  status  on  Intel  information 

Common  Effects  Picture  (59)  -  February  2006 

No. 

Requirement 

1 

Need  to  know  what  the  enemy  commander  is  thinking 

2 

Anticipate  relationships  and  decide  how  effects  are  related  to  actions 
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3 

Tools  to  support  planning,  execution  and  assessment  of  EBO 

4 

Unified  campaign,  not  a  separate  one  for  each  service 

5 

Must  anticipate  future  events 

6 

Continuously  updated  information 

7 

Staff  is  aware  of  JFACC  decision  points 

8 

Facilitate  prediction:  reevaluating  as  things  go  along 

9 

Facilitate  prediction:  anticipate  events  beforehand 

10  I 

■acilitate  prediction:  anticipating  enemy  options 

11 

Information  must  be  available  when  needed 

12 

staff  capability  to  push  information  to  JFACC 

13 

How  is  he  doing  operationally 

14 

What  effects  he  is  creating  -  intended,  unintended,  cascade 

15 

Ahead  or  behind  and  what  is  next 

16 

Develop  standard  presentations  and  MOEs 

17 

Information  must  be  actionable 

18 

Needs  operational  data,  not  tactical  data 

19 

System:  easy  to  learn 

20 

System:  play  well  with  other  services 

21 

System:  consider  from  a  "command-centric"  viewpoint 

22 

System:  Goal  understanding  from  "supported  role" 

23 

System:  synthesize  data  from  different  technologies/formats 

24 

Operational  anticipation  is  state  of  battle  space  in  terms  of  enemy  and  allied  capability 

25 

Anticipation  based  on:  intent  -  our  own  or  enemies 

26 

Anticipation  based  on:  history  -  events  from  the  past 

27 

Anticipation  based  on:  rate/trend  -  events  in/out  of  focus  area 

28 

Depict  current  state  plus  rate/trend  information 

29 

Depict  current  events  plus  events  that  may  impinge 
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30 

Depict  trend  may  require  evolution  of  states 

31 

Depict  implications  of  intent  (possibly) 

32 

Depict  system  dynamics  including  allied  and  enemy  and  actions  to  influence  events  that  are 
likely  to  unfold  with  consideration  given  to  time  constraints 

33 

Need  to  answer:  what  is  MES/OO/TO/TT  for  red  and  blue 

34 

Need  to  answer:  purpose  of  the  campaign 

35 

Need  to  answer:  how  the  campaign  is  conducted 

36 

Need  to  answer:  what  is  victory  or  the  outcome 

37 

Need  to  answer:  what  are  the  phases  of  the  campaign 

38 

Is  the  enemy  achieving  his  objectives? 

39 

Role  of  supported  versus  supporting 

40 

Job  is  to  ANTICIPATE  -  set  conditions  for  success 

41 

OA  needs  rolled  up  to  the  JFC 

42 

Need  to  create  a  Blue  view  of  Red 

43 

Have  time  relevant  information  and  scaled  properly 

44 

Effect  type  -  direct,  indirect,  cascading 

45  I 

Effect  numbered 

46  I 

Effect  geo-spatial 

47  1 

Effect  temporal 

48  I 

Effec  t  priority 

49  I 

Effect  dependencies 

50 

Effect  weight  of  effort 

51  I 

Effec  t  risk 

52 

Effect  link  to  Indirect  Effects 

53  1 

ndicato  rs:  Numbered 

54  1 

ndicato  rs:  Status 

55 

Indicators:  Location  (lat,  long) 
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56  1 

ndicato  rs:  Type 

57  1 

ndicato  r  Rank 

58 

Indicator  Scale  -  Operational,  Tactical,  Strategic,  Execution 

59 

Indicator  EBO  Type  -  complex,  cascading,  direct,  indirect 

Warfighter  Assessment  Workshop  (50)  -  April  2006 


No. 

Requirement 

1 

A  strategy  planning  tool  shall  provide  Execution  Assessment  data  including  JIPTL  Targets, 
Missions  flown  and  Status  for  both  the  missions  and  targets,  correlated  to  the  JAOP 

2 

A  strategy  planning  tool  shall  help  identify  gaps  in  the  plan 

3 

A  strategy  planning  tool  must  provide  Execution  Assessment  data  related  to  support  for  other 
components,  for  example,  through  Air  Support  Requests  (ASRs) 

4 

A  strategy  planning  tool  must  provide  non-kinetic  Execution  Assessment  data 

5 

A  strategy  planning  tool  must  provide  easy  ingestion  and  propagation  of  Execution 

Assessment  data  for  quick  look  target(HVT) 

6 

Execution  Assessment  Data  must  provide  detailed  information  about  the  actual  mission 
performed  versus  the  planned  mission 

7 

A  strategy  planning  tool  shall  provide  Assessment  data  from  OAT  in  addition  to  Execution 
Assessment  data  correlated  to  the  JAOP 

8 

A  strategy  planning  tool  must  provide  Execution  Assessment  data  with  target  details  including 
BE#,  DMPI,  and  a  link  to  the  target  folder 

9 

A  strategy  planning  tool  must  provide  Execution  Assessment  data  with  the  capability  to  define 
user-specified,  critical  events,  that  when  realized,  alert  the  user.  Two  critical  events  include  a 
re-roll  and  a  TST  (which  often  dictates  a  re-roll) 

10 

A  strategy  planning  tool  must  provide  Execution  Assessment  data  for  Missions  including 
mission  date/time,  shall  be  available 

11 

A  strategy  planning  tool  must  provide  Execution  Assessment  data  for  Missions  in  a 
spreadsheet  view  with  Excel-based  functionality.  Columns  selectable  by  user. 

12 

A  strategy  planning  tool  must  provide  the  ability  to  monitor  status  of  key  (user  defined)  targets. 

13 

A  strategy  planning  tool  must  provide  dockable  windows  to  permit  user  configurable  displays 

14 

A  strategy  planning  tool  must  provide  Execution  Assessment  mission  data  to  include  individual 
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mission  start  and  stop  times  within  the  eSync  module 

15 

A  strategy  planning  tool  must  provide  more  than  one  method,  for  example,  flowcharting, 
wizard  and  menu  driven  methodologies,  when  creating  alerts  for  Execution  Assessment  data 

16 

A  strategy  planning  tool  must  provide  Lines  of  Effects  data  that  can  be  categorized  into  user 
defined  categories  beyond  just  Military  means,  such  as  with  PMESII 

17 

A  strategy  planning  tool  must  provide  Lines  of  Effects  information  through  clear  and  simple 
visualizations  when  viewed  by  a  commander. 

18 

Leveraging  of  mouse  over  and  drill  down  techniques  could  reduce  complexity  and  user 
cognitive  load. 

19 

A  strategy  planning  tool  must  provide  Lines  of  Effects  information  with  references  to  COG  that 
includes  tailorable  types  and  associated  icons,  ones  which  address  PMESII  elements 

20 

A  strategy  planning  tool  must  provide  Lines  of  Effects  information  for  essential  tasks  through  a 
symbol  other  than  a  triangle  (target  is  implied) 

21 

A  strategy  planning  tool  must  provide  Lines  of  Effects  information  for  Supported  Component 
through  ordinal  relationships  such  as  top  LOE  is  the  Supported  Component 

22 

A  strategy  planning  tool  must  provide  capability  to  generate  in  a  briefing  level  representation 
Lines  of  Effects  information  in  the  Supported  Commander's  (or  other  as  required)  desired 
briefing  format 

23 

A  strategy  planning  tool  must  provide  Lines  of  Effects  information  with  respect  to  a  maritime 
component 

24 

A  strategy  planning  tool  must  provide  Lines  of  Effects  information  that  references  WOE, 
initially  through  raw  DMPI/sortie  equivalent  (DSEs) 

25 

A  strategy  planning  tool  must  provide  data  supporting  COG  or  SOSA  information  within  Lines 
of  Effects 

26 

A  strategy  planning  tool  containing  complex  Lines  of  Effects  information  must  include  a 
training  component  as  part  of  its  design 

27 

A  strategy  planning  tool  must  provide  a  "Return  to  Home"  with  the  Lines  of  Effects  view 

28 

A  strategy  planning  tool  must  limit  access  to  a  defined  set  of  users  for  Lines  of  Effects 
information  manipulation 

29 

A  strategy  planning  tool  must  provide  "unknown"  PMESII  elements  within  Lines  of  Effects  view 
in  gray  color 

30 

A  strategy  planning  tool  must  provide  clear  identification  of  meaning  and  perspective  for  color 
coding  and  states  used 

31 

A  strategy  planning  tool  must  specify  End-state  focus  (campaign  versus  phase)  for  provided 
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Lines  of  Effects  information 

32 

A  strategy  planning  tool  must  allow  for  easy  switching  of  End-state  focus  (campaign  versus 
phase)  for  provided  Lines  of  Effects  information 

33 

A  strategy  planning  tool  must  provide  differentiation  between  WOE  and  priority  within  Lines  of 
Effects  information 

34 

A  strategy  planning  tool  must  provide  a  capability  to  reprioritize  Plan  elements  and  attributes 
within  Lines  of  Effects  information 

35 

A  strategy  planning  tool  must  provide  Lines  of  Effects  information  with  TO  "bars"  labeled 
according  to  the  plan  with  capability  for  user  comments 

36 

A  strategy  planning  tool  must  provide  Lines  of  Effects  information  at  user  selectable  levels  of 
detail,  including  at  a  minimum  a  Campaign/End-state  view  with  drill-down  through  Phases  to 
TT/ATO  levels. 

37 

A  strategy  planning  tool  must  provide  a  Lines  of  Effect  based  planning  interface  in  order  to 
develop  the  JAOP  and  provide  a  product  which  replaces  the  AOD  as  the  output  from  SPT  to 
MAAP 

38 

A  strategy  planning  tool  must  provide  Lines  of  Effects  information  demonstrations  through 
real-world  examples 

39 

A  strategy  planning  tool  must  allow  entry  of  End-state  information  into  machine  and  human 
understandable  format  without  adding  complexity  to  the  current  entry  methodology  i.e.  textual 
descriptions,  within  the  Lines  of  Effects 

40 

A  strategy  planning  tool  must  provide  trend  information  within  Lines  of  Effects 

41 

A  strategy  planning  tool  must  provide  Lines  of  Effects  information  through  mappings  between 
COGs  and  Tos  with  progress  indicators  against  Tos 

42 

A  strategy  planning  tool  must  provide  PMESII  elements  mapped  to  00  level  and  higher 

43 

A  strategy  planning  tool  must  provide  Decision  Point  information  from  Execution  Assessment 
view  within  Lines  of  Effects 

44 

A  strategy  planning  tool  must  provide  information  supporting  anticipatory  or  predictive  analysis 

45 

46 

A  strategy  planning  tool  must  provide  Lines  of  Effects  information  that  is  filterable  by  WOE, 
priority,  and  plan  elements 

47 

A  strategy  planning  tool  providing  Lines  of  Effects  information  must  include  both  graphical  and 
text  representations 

48 

A  strategy  planning  tool  providing  Lines  of  Effects  information  must  show  inter-related  tasks 
simultaneously 
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A  strategy  planning  tool  providing  Lines  of  Effects  information  must  provide  a  drill-down 

49 

feature  for  MOEs/MOPs  and  indicators 

A  strategy  planning  tool  must  allow  for  development  and  leveraging  of  a  Prioritized  Effects  List 

50 

(PEL) 

COA  Sketch  Requirements  (85)  -  February  2007 

No. 

Requirement 

1 

Strat  Planner  can  enter  mission  tasks 

2 

Strat  Planner  can  enter  mission  statement 

3 

Strat  Planner  can  enter  Laws  of  Armed  Conflict 

4 

Strat  Planner  can  enter  Rules  of  Engagement 

5 

Strat  Planner  can  input  a  document  as  analysis  evidence 

6 

User  can  review  documents  used  as  analysis  evidence 

7 

Strat  Planner  can  enter  Center  of  Gravity 

8 

strat  Planner  can  enter  Critical  Capabilities 

9 

Strat  Planner  can  enter  Critical  Requirements 

10 

Strat  Planner  can  enter  Facts 

11 

Strat  Planner  can  enter  Assumptions 

12 

Strat  Planner  can  enter  Risks 

13 

Strat  Planner  can  enter  Commander's  Intended  Methods 

14 

strat  Planner  can  enter  Commander's  Indented  Purpose 

15 

Strat  Planner  can  enter  Commander's  Intended  End  States 

16 

Strat  Planner  can  create  new  operation  planning  project 

17 

Strat  Planner  can  open  existing  operation  planning  projects 

18 

Strat  Planner  can  save  current  operation  planning  project  under  a  new  name 

19 

strat  Planner  can  delete  an  existing  operation  planning  project 

20 

Strat  Planner  can  archive  an  existing  operation  planning  project 
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21 

Strat  Planner  can  create  new  Course  of  Action 

22 

Strat  Planner  can  delete  an  existing  Course  of  Action 

23 

Strat  Planner  can  enter  the  Validity  of  a  Course  of  Action 

24 

Strat  Planner  can  enter  the  Suitability  of  a  Course  of  Action 

25 

Strat  Planner  can  enter  the  Feasibility  of  a  Course  of  Action 

26 

strat  Planner  can  enter  the  Acceptability  of  a  Course  of  Action 

27 

Strat  Planner  can  enter  the  Distinguishability  of  a  Course  of  Action 

28 

Strat  Planner  can  enter  the  Completeness  of  a  Course  of  Action 

29 

Command  staff  can  promote  COA  to  Operational  Plan 

30 

Command  staff  can  demote  Operational  Plan  to  COA 

31 

Command  staff  can  enter  Commander's  Estimated  Course  of  Action 

32 

strat  Planner  can  enter  Objectives 

33 

Strat  Planner  can  enter  Tasks 

34 

Stat  Planner  can  enter  Actions 

35 

Strat  Planner  can  enter  Effects 

36 

Strat  Planner  can  enter  Activities 

37 

strat  Planner  must  associate  a  Level  of  War  with  each  Strategy  Object 

38 

Strat  Planner  must  provide  a  short  name  for  each  Strategy  or  Mission  Analysis  Object 

39 

Editing  users  can  associate  time  intervals  with  each  Strategy  or  Mission  Analysis  Object 

40 

Editing  users  can  associate  2-D  spatial  regions  with  each  Strategy  or  Mission  Analysis  Object 

41 

Editing  users  can  associate  2-D  spatial  regions  with  specific  time  intervals  on  a  Strategy  or 
Mission  Analysis  Object 

42 

Coordinates  of  spatial  regions  will  be  stored  using  a  single,  well-defined  coordinate  system 
(e.g.WGS84) 

43 

Maps  and  Images  that  are  not  suitable  for  targeting  will  have  a  non-removable  watermark 
stating  this  fact. 

44 

Strat  Planner  can  convert  Strategy  or  Mission  Analysis  Objects  to  compatible  types  of  object 

45 

Assessor  can  create  Measures  of  Effectiveness 
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46 

Assessor  can  create  Measures  of  Performance 

47 

Assessor  can  create  Indicators 

48 

User  identity  must  be  authenticated  before  performing  any  system  action 

49 

User  must  have  authorized  security  role  to  perform  any  system  action 

50 

User  will  authenticate  using  DoD  Common  Access  Card 

51 

Editing  Users  can  gain  exclusive  write  access  to  portions  of  system  data. 

52 

Editing  Users  cannot  hold  exclusive  write  access  indefinitely 

53 

System  visually  identifies  new  or  changed  information  the  user  has  not  previously  viewed 

54 

Editing  Users  can  undo/redo  changes  they  have  made  to  system  data 

55 

Users  can  view  change  history  of  a  planning  project  object 

56 

Editing  users  can  specify  which  groups  of  users  can  view  data  they  have  created 

57 

Strat  Planners  can  enter  Phases  of  a  Course  of  Action 

58 

Editing  users  can  specify  timing  intervals  relative  to  other  dates  or  intervals 

59 

Editing  users  can  specify  alpha-times  as  fixed  times  or  relative  to  other  dates  or  intervals 

60 

Users  can  temporarily  configure  timeline  views  to  be  relative  to  any  alpha-time  without 
changing  persistent  data 

61 

Users  can  temporarily  configure  timeline  views  to  be  presented  in  ZULU  or  local  time. 

62 

Time  views  will  not  display  calendar  data  unless  the  time  data  has  been  linked  to  a  specific 
date. 

63 

Users  can  temporarily  hide  and  show  map  objects  Individually  or  by  layer  group  without 
changing  persistent  data 

64 

Editing  users  can  alter  the  appearance  of  Individual  map  objects. 

65 

Editing  users  can  alter  the  default  appearance  of  map  objects  by  category 

66 

Users  can  temporarily  alter  the  order  of  map  object  layers  without  changing  persistent  data 

67 

Users  can  temporarily  alter  the  visibility  of  specific  objects  in  the  synchronization  view  without 
changing  persistent  data 

68 

Users  can  temporarily  alter  the  visibility  of  objects  in  the  sync  view  based  on  time  intervals 
without  changing  persistent  data 

69 

Uses  can  temporarily  alter  the  ordering  of  objects  in  the  sync  view  without  changing  persistent 
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Users  can  temporarily  alter  the  units  of  time  used  to  display  the  sync  view  without  changing 

70  persistent  data 

71  Editing  users  can  constrain  the  start  or  stop  time  of  a  timeline  to  specific  intervals  of  time 

72  Users  can  navigate  between  views  using  the  currently  selected  object 

73  User  security  roles  shall  be  defined  in  terms  of  AOC  teams 

74  Users  can  view  the  security  roles  they  are  authorized  as 

75  Strat  Planners  can  enter  COA  Statement 

76  Strat  Planners  can  enter  End  States  or  End  State  Conditions 

77  Users  can  export  and  import  operations  and  COAs  to  and  from  client-side  files 

78  System  Admins  can  register  deployment  with  NCES  registry 

79  Editing  users  can  upload  map  layer  or  map  icon  data 

80  Users  can  export  map  data  to  CIS  formats 

81  Strat  Planners  can  set  the  type  of  operation  expected  to  be  performed  during  a  phase 

82  Strat  Planners  can  set  the  expected  level  of  effort  associated  with  executing  an  strategy  object 

83  Users  can  view  sync  view  as  a  phase  table 

Users  can  temporarily  re-order  COAs  and  plans  in  the  sync  tree  to  make  comparisons  without 

84  changing  persistent  data 

85  Strat  Planners  can  associate  different  names  with  the  same  object  in  different  time  frames 

High-Level  COA  Sketch  (12)  -  April  2007 
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4 

COA  Sketch  shall  maintain  available  relationships  to  other  data  elements  both  internal  and 
external  to  COA  Sketch  for  all  imported  or  directly  referenced  data  elements 

5 

COA  Sketch  shall  assist  with  notional  Allocation  Planning 

6 

COA  Sketch  shall  provide  Apportionment  level  estimation  and  situational  awareness  based 
upon  the  notional  allocation 

7 

COA  Sketch  shall  provide  temporal  estimation  capabilities  based  upon  the  notional  allocation 
scheme 

8 

COA  Sketch  shall  allow  planners  to  designate  areas  of  effect  in  a  geographical  or  conceptual 
context 

9 

COA  Sketch  shall  allow  multiple  users  to  collaborate  on  the  development  of  one  or  more 

COAs 

10 

COA  Sketch  shall  format  briefing  material  for  the  JFACC  COA  Decision  Brief 

11 

COA  Sketch  shall  interface  to  current  planning  tools  in  order  to  automate  the  transfer  of 
nominated  and  selected  COAs 

12 

COA  Sketch  shall  interface  to  existing  systems  of  record  for  Targeting,  Execution  and 
Assessment  in  order  to  exchange  data. 
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Use  Cases”  table. 
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Mission  Analysis  Use  Cases 

Use  Case  2.2:  Strategy  Planner  enters  Mission  Tasks  Into  the  system 

User  Story  /  Context  of  Use: 

•  During  Mission  Analysis,  Strategy  Planners  will  need  to  analyze  the  Commanders 
Guidance,  Planning  Order  and  Warning  Orders  to  determine  what  the  tasks  are  so  the 
goals  that  are  accomplished  are  the  goals  set  out  by  the  Joint  Force  Commander 
(JFC).  The  Strategy  Planners  need  to  determine  both  the  specified  and  the  implied 
tasks  then  determine  which  of  these  tasks  are  mission  essential.  Capturing  this  data 
up  front  and  making  it  available  to  the  team  greatly  enhances  situational  awareness 
and  results  in  improved  analysis  by  the  Warfighter. 

•  Specified  tasks  are  those  which  are  specifically  assigned  by  the  JFC,  usually  in  a  joint 
CO  A,  OPLAN,  OPORD  or  campaign  plan. 

•  While  a  specified  task  could  appear  almost  anywhere  in  the  JFC’s  plan,  the  best 
places  to  look  are  in  “Tasks  for  Subordinates”  and  “Coordinating  Instructions”. 

•  Implied  tasks  are  additional  major  tasks,  which  are  not  specifically  stated.  They  are 
candidates  for  essential  tasks  and  for  inclusion  in  the  mission  statement. 

•  To  derive  implied  tasks  we  focus  on  analyzing  JFACC  specified  tasks,  JFC  mission, 
intent  and  concept  and  specified  tasks  to  the  other  components. 

•  Asa  technique,  look  for  implied  tasks  by  examining  these  three  questions: 

•  “In  this  situation,  what  other  major  tasks  would  a  JFACC  normally  perform?” 
e.g.,  if  air  and  space  superiority  are  not  specified  tasks  from  the  JFC,  they  are 
necessary  in  most  situations,  and  therefore  would  be  implied  tasks. 

•  “What  in  the  JFC  mission,  intent,  or  concept  implies  a  major  (but  unstated)  task 
for  the  JFACC?”  e.g.,  if  the  JFC  has  a  mission  to  deter  war,  but  that  is  not  a 
specified  JFACC  task;  won’t  the  JFACC  have  to  contribute  to  deterrence? 

•  “What  task  to  another  component  is  likely  to  require  significant  support  from  the 
JFACC?”  For  example,  if  there  is  to  be  an  amphibious  landing,  the  JFACC  is 
likely  to  need  to  support  both  preparation  for  and  execution  of  that  landing. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Strategy  Planner 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers: 

•  The  Strategy  Planner  has  determined  all  task  information  and  now  wishes  to  enter  it  into 

the  system. 

•  The  Strategy  Planner  needs  to  determine  all  task  information  and  wishes  to  use  the 

system  to  aid  in  capturing  this  data. 

Guarantees: 

•  The  following  task  information  will  be  stored  within  the  COA  Sketch  system: 

■  Name  of  task 
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■  Description  of  task 

■  Is  task  specified  or  implied? 

■  Is  the  task  mission  essential? 

■  If  valid,  start/stop  times 

■  If  valid,  sketch  view  data 

•  The  task  information  will  be  made  available  to  all  team  members  via  any  view  that 
displays  the  data. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  enter  a  new  Mission  Task  in  CO  A  Sketch. 

2.  The  system  prompts  user  for  Mission  Task  data. 

3.  The  user  enters  all  available  data  and  saves  the  Mission  Task. 

4.  The  system  stores  the  entered  data  as  a  new  Mission  Task. 

Alternative  1  -  User  modifies  Mission  Task: 

1 .  The  user  selects  a  current  Mission  Task  in  COA  Sketch. 

2.  The  system  displays  the  data  for  the  selected  task. 

3.  The  user  modifies  the  existing  data  and  saves  the  Mission  Task. 

4.  The  system  updates  the  Mission  Task  to  contain  the  new  changes. 

Requirements: 

Use  Case  2.3:  Strategy  Planner  enters  Mission  Statement  into  the 
system 

User  Story  /  Context  of  Use: 

•  During  Mission  Analysis,  the  service  component  commander’s  mission  statement  will 
be  written  or  a  mission  statement  could  be  passed  on  to  the  Strategy  Division  via  the 
JFC’s  guidance.  Capturing  the  Mission  Statement  means  it  is  available  throughout 
COA  development,  planning,  and  re-planning  processes.  This  process  enables  better 
situational  awareness  and  a  focused  plan. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers: 

•  The  Strategy  Planner  has  received  the  JFC  or  component  commander  mission  statement 
and  now  wishes  to  enter  it  into  the  system. 

•  The  Strategy  Planner  aids  the  component  commander  in  building  the  mission  statement 
and  will  use  the  system  to  aid  in  capturing  this  data. 

Guarantees: 

•  Mission  Statement  additions  or  modifications  will  be  reflected  in  the  Mission  Analysis 
View. 

•  The  Mission  Statements  will  be  shared  with  all  team  members  via  the  Mission  Analysis 
view. 

•  All  documents  relating  to  the  Mission  Statements  will  be  available. 

•  If  there  are  multiple  Mission  Statements  each  will  be  viewable  and  identified  by  source. 
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Main  Success  Scenario: 

1 .  The  user  chooses  to  enter  a  new  Mission  Statement  in  COA  Sketch. 

2.  The  system  displays  the  Mission  Statement  editor  window. 

3.  The  user  enters  relevant  data  and  saves  the  Mission  Statement. 

4.  The  system  stores  the  entered  data  as  a  new  Mission  Statement. 

Alternative  1  -  User  modifies  Mission  Statement: 

1 .  The  user  selects  a  current  Mission  Statement  in  COA  Sketch. 

2.  The  system  displays  the  Mission  Statement  editor  window  and  loads  the  data  for  the 
selected  Mission  Statement. 

3.  The  user  modifies  the  existing  data  and  saves  the  Mission  Statement. 

4.  The  system  updates  the  Mission  Statement  to  contain  the  new  changes. 

Requirements: 

Use  Case  2.4:  Strategy  Planner  enters  Law  of  Armed  Conflict  (LOAC) 
and/or  Rules  Of  Engagement  (ROE)  Information  Into  the  system 

User  Story  /  Context  of  Use: 

•  Judge  Advocate  General  (JAG)  Liaisons  will  capture  LOAC  and  ROE  information 
into  the  system  during  mission  analysis.  This  will  make  the  information  available 
during  the  COA  development,  planning,  and  re-planning  processes. 

•  The  Law  of  Armed  conflict  defines  the  conduct  and  responsibilities  of  belligerent 
nations,  neutral  nations  and  individuals  engaged  in  warfare,  in  relation  to  each  other 
and  to  protected  persons,  usually  meaning  civilians. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  JAG  Liaison 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers: 

•  The  Strategy  Planner  has  received  the  LOAC  and/or  ROE  information  and  now 
wishes  to  enter  it  into  the  system. 

Guarantees: 

•  The  LOAC  and/or  ROE  information  will  be  stored  within  the  COA  Sketch  system. 

•  The  LOAC  and/or  ROE  information  will  be  made  available  to  all  team  members  via 
the  Mission  Analysis  view. 

•  ROE  data  consists  of  when,  where  and  how  force  can  be  used. 

•  If  JAG  Liaison  associated  a  geographic  context,  then  a  Generic  Object  will  be  created 
with  the  tag  “LOAC”  or  “ROE”. 

•  The  Generic  Object  will  be  associated  back  to,  and  provide  direct  access  to,  the 
Mission  analysis  LOAC  or  ROE  data. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  enter  LOAC  and  ROE  information  in  COA  Sketch. 

2.  The  system  displays  the  LO AC/ROE. 

3.  The  user  enters  the  LO  AC/ROE  information. 

4.  The  system  stores  the  LOAC  and  ROE. 
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Alternative  1  -  User  modifies  LOAC  and  ROE  data: 

1 .  The  user  selects  LOAC  and  ROE  information  in  COA  Sketch. 

2.  The  system  displays  LOAC  and  ROE  information  editor  window  and  loads  the  data 
for  the  selected  LOAC  and  ROE. 

3.  The  user  modifies  the  existing  data  and  saves  the  LOAC  and  ROE  information. 

4.  The  system  updates  the  LOAC  and  ROE  information  to  contain  the  new  changes. 

Requirements: 

Use  Case  2.5:  Strategy  Planner  enters  Commander’s  Intent  Into  the 
system  (method,  purpose,  end  states) 

User  Story  /  Context  of  Use: 

•  The  Strategy  Planner  will  capture  the  Commander’s  method,  purpose,  and  end  state 
intent  into  the  tool  to  provide  the  team  with  access  to  this  information.  This 
information  aids  the  team  in  maintaining  situational  awareness  of  the  Commander’s 
intent  throughout  the  COA  development,  planning,  and  re-planning  processes. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers: 

•  The  Strategy  Planner  has  received  the  Commander’s  Intent  and  now  wishes  to  enter  it 
into  the  system. 

Guarantees: 

•  The  Commander’s  Intent  will  be  stored  within  the  COA  Sketch  system. 

•  The  Commander’s  Intent  will  be  made  available  to  all  team  members  via  the  Mission 
Analysis  view. 

•  System  will  prompt  for  all  relevant  data,  including:  Method,  Purpose,  and  End  States 
for  each  phase. 

Main  Success  Scenario: 

1.  The  user  chooses  to  enter  the  Commander’s  Intent  into  COA  Sketch. 

2.  The  system  displays  the  Commander’s  Intent. 

3.  The  user  enters  relevant  data.  Relevant  data  includes: 

a.  Method 

b.  Purpose 

c.  End  states  (for  each  phase) 

4.  The  system  stores  the  changes. 

Alternative  1  -  User  modifies  Commander’s  Intent: 

1.  The  user  selects  the  current  Commander’s  Intent  in  COA  Sketch. 

2.  The  system  displays  the  Commander’s  Intent  editor  with  the  current  data. 

3.  The  user  modifies  the  displayed  data  and  saves  the  changes. 

4.  The  system  stores  the  changes. 

Requirements: 
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Use  Case  2.9:  User  Adds/removes  document  to  list  of  documents 
gathered  for  Analysis 

User  Story  /  Context  of  Use 

•  During  Mission  Analysis  the  user  will  have  the  opportunity  to  review  and  analyze  many 
documents.  The  COA  Sketch  system  will  permit  the  user  to  store  any  and  all  documents 
related  to  the  analysis. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
User  Impact: 

•  Allows  user  to  incorporate  electronic  documents  into  the  COA  Sketch  system. 

•  These  documents  can  then  be  used  to  add  information  such  as  facts,  assumptions, 
specified  tasks,  etc.  to  COA  Sketch  tools. 

•  Any  information  added  to  COA  Sketch  tools  will  be  traceable  from  the  tool  directly 
to  the  original  document. 

Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers:  The  Strategy  Planner  receives  a  document  for  analysis. 

Guarantees: 

•  The  document  will  be  stored  in  the  COA  Sketch  system. 

•  The  document  will  be  available  to  the  team  members  via  the  Mission  Analysis  view. 

•  All  data  will  maintain  traceability  information  to  the  original  document  (document  name,  page 
number,  selected  text,  date  created,  edits,  creator  of  object  etc.). 

Main  Success  Scenario: 

1 .  User  receives  guidance  document. 

2.  User  chooses  to  add  document  to  document  list. 

3.  The  system  requests  the  location/url,  file  name,  user-defined  name,  and  type 
(Warning  order,  etc)  of  the  document. 

4.  The  user  indicates  the  location/url,  file  name,  user-defined  name,  and  type  of  the 
document 

5.  The  system  verifies  that  the  document  location  and  file  name  is  valid. 

6.  The  system  verifies  that  the  user-defined  name  is  valid. 

7.  The  system  verified  the  type  of  document  is  valid. 

8.  The  system  stores  the  collected  information. 

9.  They  system  displays  confirmation  to  the  user  that  the  document  was  successfully 
added. 

Alternative  1  -  User  deletes  document  from  system: 

1 .  User  opens  document  list. 

2.  User  selects  document. 

3.  User  deletes  document  from  list. 

Alternative  2  -  File  location  error: 

5.  System  cannot  verify  document  location  and  filename. 

6.  System  displays  error  message. 

7.  Return  to  Step  3. 
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Alternative  3  -  User  does  not  enter  a  document  type: 

5.  System  detects  no  file  type  entered. 

6.  System  prompts  for  file  type. 

7.  User  enters  file  type  or  cancels  prompt. 

8.  The  system  stores  the  collected  information. 

9.  They  system  displays  confirmation  to  the  user  that  the  document  was  successfully 
added. 

Alternative  4  -  User  does  not  enter  a  valid  filename: 

7.  System  detects  invalid  filename. 

8.  System  informs  user  of  reason  for  invalid  filename. 

9.  System  prompts  for  valid  filename. 

10.  The  system  verifies  that  the  user-defined  name  is  valid. 

1 1 .  The  system  stores  the  collected  information. 

12.  They  system  displays  confirmation  to  the  user  that  the  document  was  successfully 
added. 

Requirements: 

Implementation  ideas: 

•  Add 

o  Drag  document  onto  “lisf  ’  icon 

o  Right-click,  “Add  to  list” 

•  Delete 

o  Right-click  on  document  in  list,  select  delete, 

o  Drag  document  from  list  to  trashcan. 

o  Delete  document  from  Windows  Explorer  type  app. 

•  Mark  as 

o  Right-click,  “Mark  as. . .” 

o  Drag  onto  listing  of  document  “types” 

•  A  Windows  Explorer-like  app  solves  all  of  these  document  management  problems. 

Use  Case  2.10:  User  opens  a  document  that  has  been  saved  in  the 
system 

User  Story  /  Context  of  Use: 

•  In  the  process  of  Mission  Analysis  the  user  has  created  a  repository  of  guidance  and 
related  documents. 

•  When  searching  for  specific  guidance,  creating  briefings,  creating  a  mission  statement 
or  other  tasks  the  user  will  want  to  view  the  full  list  of  documents  prior  to  selecting 
one  to  view. 

•  After  selecting  a  document  the  COA  Sketch  system  will  open  the  document. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers:  User  needs  to  search  guidance  document  for  information. 
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Guarantees: 

•  The  CO  A  Sketch  system  will  store  a  list  of  documents. 

•  The  user  will  be  able  to  access  the  list  of  documents. 

•  The  user  will  be  able  to  open  documents. 

Main  Success  Scenario: 

1 .  User  chooses  to  view  documents  list. 

2.  User  opens  document  list. 

3.  System  displays  document  list. 

4.  User  selects  document. 

5.  System  opens  document. 

Alternative  1: 

Requirements: 

Implementation  ideas: 

•  Provide  “open  folder”  icon  to  access  list.  Clicking  folder  will  open  Windows  Explorer 
type  view  of  document  list. 

Use  Case  2.11:  User  creates  COA  Sketch  object  from  selected 
document 

User  Story  /  Context  of  Use: 

•  In  the  process  of  COA  development/analysis  the  user  will  create  briefings,  a  mission 
statement  and  other  tasks  based  on  guidance  documents  stored  in  COA  Sketch. 

•  When  viewing  guidance  documents,  the  user  will  have  the  ability  to  create  an  object 
by  transferring  information  directly  from  the  document  into  the  COA  Sketch  tools. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

•  User  has  opened  document  from  list. 

Triggers:  User  needs  to  search  guidance  document  for  information. 

Guarantees: 

•  The  COA  Sketch  system  will  store  a  list  of  documents. 

•  The  user  will  be  able  to  access  the  list  of  documents. 

•  The  user  will  be  able  to  open  documents. 

•  The  user  will  be  able  to  interact  with  documents  to  create  objects. 

Main  Success  Scenario: 

1 .  User  selects  data  from  document. 

2.  User  selects  to  create  object  with  selected  data. 

3.  System  shows  selected  data. 

4.  System  creates  object. 

5.  System  stores  traceability  data  (document  name,  page  number,  selected  text,  date 
created,  edits,  creator  of  object  etc.). 

Alternative  1  -  User  edits  object  data: 

1 .  User  selects  object  for  data  editing. 
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2.  System  displays  editing  fields. 

3.  User  edits  data. 

4.  System  saves  new  data  and  closes  editor. 

Requirements: 

Implementation  ideas: 

•  Highlight  text  in  document,  right-click,  select  “Move  to  Facts”,  “Move  to 
Assumptions”,  “Create  Tactical  Task”  etc. 

•  Highlight  text,  click  and  drag  into  list,  map,  Synch  view. . . 

•  Right-click  existing  object,  select  “Delete”  from  menu. 


Use  Case  2.12:  User  views  traceability  of  Mission  Analysis  object 

User  Story  /  Context  of  Use: 

•  In  the  process  of  Mission  Analysis  (MA)  the  user  will  create  briefings,  a  mission 
statement  and  other  tasks  based  on  guidance  documents  stored  in  COA  Sketch. 

•  When  viewing  guidance  documents,  the  user  will  have  the  ability  to  create  an  object 
by  transferring  information  directly  from  the  document  into  the  COA  Sketch  tools. 

•  Any  object  created  by  the  system  may  be  questioned  in  the  future.  To  verify  accuracy 
and  currency  of  data  all  created  objects  will  maintain  traceability  to  their  source. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

•  The  MA  View  is  open. 

Triggers:  User  needs  to  find  guidance  document  used  to  create  object. 

Guarantees: 

•  The  COA  Sketch  system  will  store  a  MA  objects. 

•  The  user  will  be  able  to  view  traceability  of  MA  objects. 

•  The  user  will  be  able  to  open  documents  referenced  in  the  traceability  data. 

•  The  system  will  store  traceability  data  (See  Use  Case:  User  creates  COA  Sketch 
object  from  selected  document) 

Main  Success  Scenario: 

1 .  User  chooses  to  view  a  MA  object. 

2.  User  selects  to  view  traceability  info  of  MA  object. 

3.  System  displays  traceability  data  for  MA  object. 

4.  User  selects  to  close  traceability  data. 

5.  System  closes  traceability  data. 

Alternative  1  -  User  opens  document  after  viewing  traceability  information: 

5.  User  chooses  to  open  document  from  traceability  info. 

6.  System  opens  original  document. 

Requirements: 

Implementation  ideas: 
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1 .  Right-click  on  object,  Select  “View  Traceability”. 

2.  Provide  traceability  data  in  editing  windows. 

3.  To  open  document,  double-click  on  document  title  wherever  traceability  information 
is  displayed. 

Use  Case  2.15:  User  creates  centers  of  gravity  (COG) 

User  Story  /  Context  of  Use: 

•  COG  determination  should  be  done  at  the  JFC  or  higher  level  and  passed  to  the  components; 
however,  component  staffs  should  be  prepared  to  provide  their  input. 

•  An  awareness  of  the  COGs  will  help  shape  what  you  want  to  affect/attack  and  what  you  need 
to  protect/defend.  Further,  it  helps  to  determine  the  tasks  the  airman  is  to  accomplish,  as  they 
will  be  analyzed  as  an  input  to  the  next  phase,  COA  development. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
User  Impact: 

Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers:  The  Strategy  Planner  wishes  to  develop  COGS. 

Guarantees: 

•  Documents  with  potential  COG-related  data  will  be  stored  in  the  COA  Sketch  system. 

•  User  will  be  able  to  access  these  documents. 

Main  Success  Scenario: 

1 .  User  chooses  to  enter  COGs. 

2.  System  prompts  for  data. 

3.  User  enters  COG  data. 

4.  System  saves  COG  data. 

Alternative  1  -  User  cancels  COG  entry: 

4.  User  cancels  COG  data  entry. 

Alternative  2  -  User  views  COG: 

1 .  User  chooses  to  view  COGs. 

2.  System  displays  COGs. 

Alternative  3  -  User  modifies  COG  entry: 

1 .  User  chooses  to  view  COGs. 

2.  System  displays  COGs. 

3.  User  modifies  COG  entry. 

4.  System  saves  COG  data. 

Alternative  3  -  User  cancels  modification  of  COG  entry: 

1 .  User  chooses  to  view  COGs. 

2.  System  displays  COGs. 

3.  User  modifies  COG  entry. 

4.  User  cancels  COG  data  modification. 

Requirements: 

Current  techniques: 
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Implementation  ideas: 

1 .  An  approach  may  be  to  organize  the  analysis  on  Political,  Military,  Economic,  Social, 
Infrastructure,  and  Information  (PMESII),  using  questions  similar  to  those  used  to 
identify  “facts”.  However,  the  focus  in  this  case  is  on  the  sources  of  strength 
essential  to  the  accomplishment  of  our  mission  and  the  vulnerabilities  through  which 
the  adversary  may  affect  those  strengths. 

2.  Whiteboard-type  capability  to  build  a  concept  map  (Systems  of  Systems  approach)  of 
CC-CR-CV.  More  complete  analysis.  Would  like  to  bring  COGs  and 
Capabilities/Will  together  (provide  a  better  understanding).  Rank  order 
capabilities/vulnerabilities  according  to  degrees  (most-least  vulnerable,  most-least 
capable).  Top  5. 

3.  Include  both  strategic  and  operational  COGs.  Step  planner  through  assessment 
process  CC-CR-CV  for  each. 


Use  Case  2.16:  User  creates  critical  capabilities 

User  Story  /  Context  of  Use: 

•  COG  determination  (including  critical  capabilities)  should  be  done  at  the  JFC  or  higher  level 
and  passed  to  the  components;  however,  component  staffs  should  be  prepared  to  provide  their 
input. 

•  However,  an  awareness  of  the  COGs  will  help  shape  what  you  want  to  affect/attack  and  what 
you  need  to  protect/defend.  Further,  it  helps  to  determine  the  tasks  the  airman  is  to 
accomplish,  as  they  will  be  analyzed  as  an  input  to  the  next  phase,  COA  development. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
User  Impact: 

Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers:  The  Strategy  Planner  wishes  to  develop  Critical  Capabilities. 

Guarantees: 

•  Documents  with  potential  Critical  Capability  related  data  will  be  stored  in  the  COA  Sketch 
system. 

•  Critical  Capabilities  may  consists  of:  name,  alliance,  description  etc. 

•  User  will  be  able  to  access  these  documents. 

Main  Success  Scenario: 

1.  User  analyzes  JFC  documents  and  other  information  for  friendly  critical  capabilities. 

2.  User  selects  data  to  save  as  critical  capability. 

3.  User  enters  data  as  critical  capability. 

4.  System  stores  critical  capability  data. 

Alternative  1  -  User  associates  critical  capability  to  COG: 

1 .  User  selects  critical  capability  data. 

2.  User  associates  data  with  COG. 

3.  System  stores  association  between  CC  and  COG. 
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Requirements: 

Current  techniques: 

Implementation  ideas: 

1 .  An  approach  may  be  to  organize  the  analysis  on  PMESII,  using  questions  similar  to 
those  used  to  identify  “facts”.  However,  the  focus  in  this  case  is  on  the  sources  of 
strength  essential  to  the  accomplishment  of  our  mission  and  the  vulnerabilities 
through  which  the  adversary  may  affect  those  strengths. 

2.  Whiteboard-type  capability  to  build  a  concept  map  (Systems  of  Systems  approach)  of 
CC-CR-CV.  More  complete  analysis.  Would  like  to  bring  COGs  and 
Capabilities/Will  together  (provide  a  better  understanding).  Rank  order 
capabilities/vulnerabilities  according  to  degrees  (most-least  vulnerable,  most-least 
capable).  Top  5. 

3.  Include  both  strategic  and  operational  COGs.  Step  planner  through  assessment 
process  CC-CR-CV  for  each. 


Use  Case  2.17:  User  creates  critical  requirements 

User  Story  /  Context  of  Use: 

•  COG  determination  (including  critical  requirements)  should  be  done  at  the  JFC  or  higher  level 
and  passed  to  the  components;  however,  component  staffs  should  be  prepared  to  provide  their 
input. 

•  However,  an  awareness  of  the  COGs  will  help  shape  what  you  want  to  affect/attack  and  what 
you  need  to  protect/defend.  Further,  it  helps  to  determine  the  tasks  the  airman  is  to 
accomplish,  as  they  will  be  analyzed  as  an  input  to  the  next  phase,  COA  development. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
User  Impact: 

Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers:  The  Strategy  Planner  wishes  to  develop  Critical  Requirements. 

Guarantees: 

•  Documents  with  potential  Critical  Requirement  related  data  will  be  stored  in  the  COA 
Sketch  system. 

•  Critical  Requirements  may  consists  of:  name,  alliance,  vulnerability,  description  etc. 

•  User  will  be  able  to  access  these  documents. 

Main  Success  Scenario: 

1 .  User  analyzes  JFC  documents  and  other  information  for  critical  requirements. 

2.  User  selects  data  to  save  as  critical  requirements. 

3.  User  enters  data  as  critical  requirements. 

4.  System  stores  critical  requirements  data. 

Alternative  1  - : 

1. 

Requirements: 

Current  techniques: 
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Implementation  ideas: 

1 .  An  approach  may  be  to  organize  the  analysis  on  PMESII,  using  questions  similar  to 
those  used  to  identify  “facts”.  However,  the  focus  in  this  case  is  on  the  sources  of 
strength  essential  to  the  accomplishment  of  our  mission  and  the  vulnerabilities 
through  which  the  adversary  may  affect  those  strengths. 

2.  Whiteboard-type  capability  to  build  a  concept  map  (Systems  of  Systems  approach)  of 
CC-CR-CV.  More  complete  analysis.  Would  like  to  bring  COGs  and 
Capabilities/Will  together  (provide  a  better  understanding).  Rank  order 
capabilities/vulnerabilities  according  to  degrees  (most-least  vulnerable,  most-least 
capable).  Top  5. 

3.  Include  both  strategic  and  operational  COGs.  Step  planner  through  assessment 
process  CC-CR-CV  for  each. 


Use  Case  2.19:  User  identifies  and  creates  facts 

User  Story  /  Context  of  Use 

•  Users  need  to  identify  facts  related  to  the  mission  and  facts  can  come  in  a  variety  of 
different  documents.  Users  need  to  analyze  Orders,  planning  products  and  JFC 
mission  and  intent  to  identify  facts. 

•  Facts  are  statements  of  known  data  concerning  the  situation,  including  adversary  and 
friendly  dispositions,  available  air  capabilities/forces,  unit  strengths,  and  material 
readiness. 

•  When  a  Fact  is  identified  the  user  needs  to  include  it  in  a  list  of  Known  Facts  for  later 
use. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

User  Impact: 

•  This  step  is  concerned  with  gathering  as  much  information  about  the  situation  as 
possible  for  analysis.  The  JFACC  staff  should  analyze  not  only  the  JFC’s  intent,  but 
the  intent  at  all  levels  of  command  up  to  and  including  the  President  of  the  United 
States  (POTUS).  The  staff  must  ensure  they  completely  understand  the  JFC’s  intent, 
mission,  limitations,  risk,  the  joint  operating  area  (JOA),  missions  of  other 
components,  and  at  least  a  general  timeline.  A  clear  understanding  of  the  JFC’s 
mission  is  vital  to  the  air  component’s  ability  to  support  the  overall  effort. 

•  It  is  critical  for  the  user  to  identify  facts  and  assumptions  and  determine  the 
differences  between  them. 

Primary  Actor:  Strategy  Planner 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers:  The  Strategy  Planner  wishes  to  identify  Facts. 

Guarantees: 

•  The  user  will  be  able  to  store  the  Facts  in  the  COA  Sketch  system. 

•  The  Facts  will  be  available  to  the  team  members  via  the  Mission  Analysis  view. 

•  The  COA  Sketch  system  will  maintain  traceability  to  the  source  document. 

Main  Success  Scenario: 
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1 .  The  user  chooses  to  enter  a  new  fact. 

2.  The  system  prompts  user  for  fact  data. 

3.  The  user  enters  all  available  facts. 

4.  The  system  stores  the  entered  data  as  a  fact. 

Requirements: 

Current  techniques: 

Implementation  ideas: 

•  Drag  and  drop  items  from  guidance  documents  into  “Facts’ 


list. 


Use  Case  2.20:  User  identifies  and  creates  assumptions 

User  Story  /  Context  of  Use 

•  Users  need  to  identify  assumptions  related  to  the  mission  and  assumptions  can  come 
in  a  variety  of  different  documents.  Users  need  to  analyze  Orders,  planning  products 
and  JFC  mission  and  intent  to  identify  assumptions. 

•  Assumptions  are  suppositions  about  the  current  or  future  situation  that  are  necessary 
to  continue  planning  and  are  assumed  to  be  true  in  the  absence  of  facts. 

•  When  an  Assumption  is  identified  the  user  needs  to  include  it  in  a  list  of  Assumptions 
for  later  use. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

User  Impact: 

•  This  step  is  concerned  with  gathering  as  much  information  about  the  situation  as 
possible  for  analysis.  The  JFACC  staff  should  analyze  not  only  the  JFC’s  intent,  but 
the  intent  at  all  levels  of  command  up  to  and  including  the  POTUS.  The  staff  must 
ensure  they  completely  understand  the  JFC’s  intent,  mission,  limitations,  risk,  the 
joint  operating  area  (JOA),  missions  of  other  components,  and  at  least  a  general 
timeline.  A  clear  understanding  of  the  JFC’s  mission  is  vital  to  the  air  component’s 
ability  to  support  the  overall  effort. 

Primary  Actor:  Strategy  Planner, 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers:  The  Strategy  Planner  wishes  to  identify  Assumptions. 

Guarantees: 

•  The  user  will  be  able  to  store  the  Assumptions  in  the  COA  Sketch  system. 

•  The  Assumptions  will  be  available  to  the  team  members  via  the  Mission  Analysis 
view. 

•  The  COA  Sketch  system  will  maintain  traceability  to  the  source  document. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  enter  a  new  assumption. 

2.  The  system  prompts  user  for  assumptions. 

3.  The  user  enters  all  available  assumptions. 

4.  The  system  stores  the  entered  data  as  assumptions. 

Alternative  1  -  User  changes  assumption  to  fact: 

1.  User  accesses  assumptions  list. 
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2.  User  changes  assumption  to  fact. 

3.  System  removes  object  from  assumption  list. 

4.  System  moves  object  to  facts  list. 


Requirements: 

Current  techniques: 

Implementation  ideas: 

•  Drag  and  drop  items  from  guidance  documents  into  “Assumptions”  list. 


Use  Case  2.21:  User  identifies  and  creates  iimitations 

User  Story  /  Context  of  Use 

•  Users  need  to  identify  limitations  related  to  the  mission  and  limitations  can  be 
identified  in  a  variety  of  different  documents.  Users  need  to  analyze  Orders,  planning 
products  and  JFC  mission  and  intent  to  identify  limitations. 

•  Limitations  on  our  operations  include  constraints,  restraints,  and  other  factors  (e.g., 
weather,  terrain,  etc.).  Constraints  are  things  which  you  must  do,  and  restraints  are 
things  which  you  must  not  do.  For  example,  if  a  combined  staff  to  include  other 
nation  participation  is  directed,  that  is  a  constraint.  An  example  of  a  restraint  might 
be  a  prohibition  from  overflying  certain  territory. 

•  When  a  limitation  is  identified  the  user  needs  to  include  it  in  a  list  of  Known 
Limitations  for  later  use. 

•  Limitations  on  our  operations  include  constraints,  restraints,  and  other  factors  (e.g., 
weather,  terrain,  etc.).  Constraints  are  things  which  you  must  do,  and  restraints  are 
things  which  you  must  not  do.  For  example,  if  a  combined  staff  to  include  other 
nation  participation  is  directed,  that  is  a  constraint.  An  example  of  a  restraint  might 
be  a  prohibition  from  overflying  certain  territory. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

User  Impact: 

Primary  Actor:  Strategy  Planner 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers:  The  Strategy  Planner  receives  a  Warning  Order,  Planning  Order,  Alert  Order,  JFC 

OPLAN  or  OPORD  and  wishes  to  identify  Facts. 

Guarantees: 

•  The  user  will  be  able  to  store  the  Limitations  in  the  COA  Sketch  system. 

•  The  Limitations  will  be  available  to  the  team  members  via  the  Mission  Analysis  view. 

•  Limitations  can  be  identified  as  constraints,  restraints  or  other  factors. 

•  The  COA  Sketch  system  will  maintain  traceability  to  the  source  document. 

Main  Success  Scenario  -  Constraints: 

1 .  User  analyzes  guidance  documents  for  constraints. 

2.  User  selects  constraints  in  COA  Sketch  system. 

3.  User  enters  constraints  into  COA  Sketch  system. 

4.  System  creates  constraint  in  limitations  list. 
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5.  System  stores  traceability  data. 

Alternative  1  -  Restraints: 

1 .  User  analyzes  guidance  documents  for  restraints. 

2.  User  selects  restraints  in  COA  Sketch  system. 

3.  User  enters  restraints  into  COA  Sketch  system. 

4.  System  creates  restraints  in  limitations  list 

5.  System  stores  traceability  data. 

Alternative  2  -  Other: 

1 .  User  analyzes  guidance  documents  for  Other  limitations. 

2.  User  selects  other  limitations  in  COA  Sketch  system. 

3.  User  enters  Other  limitations  into  COA  Sketch  system. 

4.  System  creates  Other  limitations  in  limitations  list 

5.  System  stores  traceability  data. 

Requirements: 

Current  techniques: 

Implementation  ideas: 

•  Drag  and  drop  items  from  guidance  documents  into  “Limitations”  list. 


Use  Case  2.22:  User  analyzes  the  tasks,  operational  environment  and 
resources  to  form  an  initial  risk  assessment 

User  Story  /  Context  of  Use 

•  Given  the  capabilities  of  the  adversary,  the  tasks  which  must  be  accomplished  and  the 
air  forces  available  to  do  them,  the  staff  can  prepare  an  initial  risk  assessment.  For 
example,  if  the  adversary  has  a  significant  offensive  air  and  missile  capability,  how 
great  is  the  risk  of  deploying  our  aircraft  within  range  of  enemy  aircraft  and  missiles 
prior  to  deploying  our  Patriot  assets? 

•  If  there  is  an  immediate  need  for  interdiction  and  CAS  in  order  to  help  stop  an 
invasion,  this  may  require  moving  assets  forward  in  the  deployment  plan  ahead  of 
some  air  defense  or  other  assets  scheduled  for  early  deployment. 

•  In  this  situation,  is  the  JFACC  (and  JFC)  willing  to  take  risks  from  an  air  defense 
viewpoint?  How  many  days  of  deployment  do  we  need  to  have  completed  before  we 
can  prevent  enemy  air/missile  from  inflicting  significant  casualties  on  the  Coalition? 

•  Commanders,  not  staffs,  bear  the  authority  and  responsibility  for  making  the  tough 
decisions  when  risk  must  be  accepted  in  one  area  or  another. 

•  The  job  of  staffs  is  to  anticipate  and  communicate  those  risk  considerations  as  early  as 
possible  so  the  JFACC  can  decide  how  best  to  minimize  and  prepare  for  the  risks. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

Triggers:  The  Strategy  Planner  wishes  to  perform  a  risk  assessment. 

Guarantees: 

•  The  user  will  be  able  to  store  the  initial  risk  analysis  in  the  COA  Sketch  system. 
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•  The  initial  risk  analysis  will  be  available  to  the  team  members  via  the  Mission 
Analysis  view. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  enter  new  risk  data. 

2.  The  system  prompts  user  for  risk  data. 

3.  The  user  enters  all  available  risks. 

4.  The  system  stores  the  entered  data  as  a  risk  assessment. 

Alternative  1: 

Requirements: 

Current  techniques: 

Implementation  ideas: 

1 .  Geospatial  and  synchronization  views  of  enemy  capabilities  along  with  friendly 
capabilities  over  time. 

2.  Mission,  casualties,  and  time  -  methods  of  evaluating  risk.  Show  alternative 
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Plan/Operation  Use  Cases 

Use  Case  3.1:  Create  new  operation 

User  Story  /  Context  of  Use: 

•  When  a  Strategy  Planner  or  team  is  ready  to  begin  the  planning  process,  the  Strategy 
Planner  will  need  to  create  a  new  operation  within  the  tool.  After  creating  the 
operation  the  team  will  have  access  to  tools  that  will  aid  in  Mission  Analysis,  COA 
Development  and  COA  Analysis. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions:  COA  Sketch  is  open. 

Triggers:  Strategy  Planner  would  like  to  create  a  new  operation. 

Guarantees: 

•  A  new  operation  will  be  created  and  stored  within  the  system. 

•  An  operation  will  define  operation  level  default  values  for  the  following  attributes, 
some  of  which  maybe  over  written  as  indicated  in  the  appropriate  use  cases: 

o  name 
o  D-day 
o  C-day 
o  M-day 

o  Other  user  defined  alpha-days 
o  Phases 

■  Title 

■  Duration 

■  Start  Date 

o  ATO  information 

■  Duration  (every  8  hours,  24  hours,  etc. . .) 

■  Start  Time  (00:00,  08:00,  12:00,  etc. . .) 

■  GMT/ZULU  or  local 

Main  Success  Scenario: 

1 .  The  user  selects  to  create  a  new  plan  from  COA  Sketch. 

2.  The  system  prompts  the  user  for  an  operation  name. 

3.  The  system  determines  the  operation  name  is  unique  and  persists  the  data. 

4.  The  system  will  set  the  following  data  by  default: 

■  D-Day  will  be  set  as  the  default  date  and  the  actual  date  will  be  left 
unspecified. 

■  C-Day  will  be  set  as  D+0. 

■  M-Day  will  be  set  as  D+0. 

■  The  time  zone  will  default  to  ZULU. 

5.  The  system  restores  the  initial  program  state. 

Alternative  1  (Operation  name  is  not  unique,  user  overwrites  old  operation): 

3.  The  system  determines  that  the  operation  is  not  unique  and  prompts  the  user  to  either 
rename  the  new  operation  or  ask  to  overwrite  the  existing  operation. 
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4.  The  user  elects  to  overwrite  the  existing  operation. 

5.  The  system  persists  the  new  operation  data  with  the  elected  name,  effectively  deleting 
the  operation  previously  stored  with  that  name. 

Requirements: 

1 .  CO  A  Sketch  shall  allow  users  to  store  the  collection  of  information  gathered  during 
the  planning  process. 

Use  Case  3.2:  Save  Existing  operation  as  new  operation 

User  Story  /  Context  of  Use: 

•  When  a  Strategy  Planner  or  team  is  ready  to  begin  the  planning  process,  the  Strategy 
Planner  will  need  to  create  a  new  operation  within  the  tool.  The  Strategy  Planner 
may  do  this  by  opening  an  existing  operation  and  saving  it  as  a  new  one.  This  may 
save  a  lot  of  the  team’s  time  by  re-entering  some  of  the  same  information  that  could 
apply  to  the  new  operation  as  well. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  At  least  one  operation  already  exists. 

Triggers:  Strategy  Planner  would  like  to  create  a  new  operation  from  an  existing  one. 
Guarantees:  A  new  operation  will  be  created  and  stored  within  the  system  that  contains  all 
the  information  from  the  already  existing  operation. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  save  operation  as  new  operation. 

2.  The  system  prompts  for  new  operation’s  name. 

3.  The  user  provides  the  new  operation’s  name. 

4.  The  system  determines  that  the  provided  operation  name  is  unique. 

5.  The  system  saves  the  current  operation  as  a  new  operation  under  the  provided  name. 
Alternative  1  (overwriting  an  existing  operation): 

3.  The  user  provides  an  existing  operation’s  name. 

4.  The  system  determines  that  the  provided  operation  name  is  not  unique. 

5.  The  system  prompts  for  confirmation  to  overwrite  existing  operation. 

6.  The  user  accepts  overwriting  the  existing  operation. 

7.  The  system  overwrites  the  existing  operation  with  the  current  operation’s  data. 
Alternative  2  (avoiding  overwriting  an  existing  operation): 

3.  The  user  provides  an  existing  operation’s  name. 

4.  The  system  determines  that  the  provided  operation  name  is  not  unique. 

5.  The  system  prompts  for  confirmation  to  overwrite  existing  operation. 

6.  The  user  declines  overwriting  the  existing  operation. 

7.  The  system  returns  to  step  2. 

Requirements: 

2.  COA  Sketch  shall  allow  the  user  to  edit  and  save  the  current  planning  process 
information. 
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Use  Case  3.3:  Open  existing  operation 

User  Story  /  Context  of  Use: 

•  As  planning  can  be  a  very  long  lived  process,  after  a  days  worth  of  work  the  team 
member  ends  their  day  and  saves  the  operation.  To  be  able  to  return  to  previously 
saved  point  in  the  development  process  a  planner  will  need  to  reopen  the  plan  to 
continue  its  development. 

•  After  completing  a  plan,  the  developers  save  their  work  from  the  terminal  they  are 
working  on.  They  then  schedule  a  review  meeting  to  cover  each  of  the  COAs 
described  in  the  operation  at  a  later  time  in  a  different  location.  They  will  need  to  be 
able  to  open  for  viewing  and  review  the  operation  and  COAs  developed  prior. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  COA  Sketch  must  have  a  operation  already  stored  in  the  system  to  be  opened. 
Triggers:  Team  member  or  reviewer  wants  to  open  up  a  saved  operation. 

Guarantees: 

•  The  existing  operation  will  be  opened  in  the  tool. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  open  an  existing  operation. 

2.  The  system  displays  a  list  of  available  operations. 

3.  The  user  chooses  one  of  the  available  operations. 

4.  The  system  opens  the  selected  operation. 

Requirements: 

2.  COA  Sketch  shall  allow  the  user  to  edit  and  save  the  current  planning  process 
information. 


Use  Case  3.4:  User  views/modifies  Operation  details 

User  Story  /  Context  of  Use: 

•  A  Strategy  Planner  may  not  initially  know  certain  details  pertaining  to  a  operation, 
such  as  how  long  a  particular  phase  will  last.  After  determining  this  information,  from 
an  order  or  planning  calculation,  they  will  wish  to  share  this  knowledge  with  the  rest 
of  the  team. 

•  After  any  portion  of  development  within  a  operation,  or  to  double  check  data  entry  on 
the  details  of  a  operation  a  Strategy  Planner  may  wish  to  view  the  operation  details 
for  accuracy  or  critique. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  plan  is  open  in  COA  Sketch. 
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•  An  operation  is  open  that  has  at  least  one  COA. 

Triggers:  Strategy  Planner  would  like  to  set  up  or  change  the  battle  rhythm  or  important 
military  dates  associated  with  a  plan. 

Guarantees: 

•  The  following  are  the  attributes  of  a  operation  that  may  be  edited  via  this  view: 

■  Name 

■  D-Day 

■  C-Day 

■  M-Day 

■  Phases 

•  Title 

•  Duration,  in  days 

•  Start  Date,  which  references  an  Alpha  Day 

•  By  default,  the  first  new  phase  will  begin  on  D+0  and  end  24  hours 
later.  All  new  phases  will  by  default  be  added  to  the  end  of  the  phases 
and  will  begin  directly  after  the  last  phase  and  last  24  hours. 

•  Removing  a  Phase: 

•  All  following  phases  will  be  adjusted  to  replace  the  removed 
phase.  If  the  removed  phase  lasted  50  days,  but  began  30  days 
before  the  second  phase,  all  phases  will  be  adjusted  30  days. 

•  Removing  the  last  phase  will  not  result  in  any  changes 

■  Mission  Statement 

■  ATO  information 

•  Duration  (every  8  hours,  24  hours,  etc...) 

•  Start  Time  ( 00:00,  08:00,  12:00,  etc...) 

•  GMT/ZULU  or  local 

•  The  system  will  store  new  important  date  information. 

•  The  system  will  update  plan  timing  information  that  may  exist  due  to  changes  made 
in  either  dates  or  battle  rhythm. 

•  The  new  Phase  timing  information  will  be  stored  within  the  COA  Sketch  system. 

•  All  visualizations  depending  upon  this  information  will  be  updated  to  reflect  the 
changes. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  edit  the  operation  details. 

2.  The  system  displays  the  operation  editor. 

3.  The  user  modifies  the  available  data. 

4.  The  user  indicates  they  are  completed  in  making  changes  to  operation  details. 

5.  The  system  stores  the  changes  and  adjusts  the  affected  views  and  objects. 

Requirements: 

3.  COA  Sketch  shall  save  system  displays  and  details  of  a  planning  process  to  aid  the  user 
in  re-immersing  themselves  back  into  the  planning  process. 

4.  COA  Sketch  shall  save  system  displays  and  details  of  a  planning  process  to  brief  or  show 
team  members  context  of  the  planning  process. 
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Use  Case  3.5:  Delete/Archive  Operation 

User  Story  /  Context  of  Use: 

•  After  beginning  a  new  operation,  the  team  is  instructed  that  they  will  no  longer  be 
responsible  for  the  operation.  Thus  to  alleviate  storage  the  user  decides  to  delete  a 
operation. 

•  Once  a  operation  has  been  fully  developed,  executed  and  completed,  it  is  no  long 
necessary  to  keep  this  data  available  for  review  and  modification.  Thus  the  user 
selects  to  delete  the  operation  from  view  so  that  it  isn’t  listed  in  the  active 
operation  list  referenced  in  opening  an  existing  operation. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  An  operation  is  open. 

Triggers: 

•  A  team  member  selects  an  operation  for  deletion. 

Guarantees: 

•  The  Operation  is  deleted  without  affecting  any  other  operations. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  delete  the  current  operation. 

2.  The  system  prompts  the  user  for  permanently  deleting  the  operation. 

3.  The  user  selects  permanent  deletion. 

4.  The  system  deletes  the  operation. 

Alternative  1  (User  cancels  delete): 

3.  The  user  elects  to  cancel  the  delete. 

4.  The  system  reverts  to  its  previous  state. 

Alternative  2  (User  chooses  to  archive  instead  of  fully  purge  the  deleted  operation): 

3.  The  user  selects  archiving, 

4.  The  system  moves  the  operation  from  the  list  of  available  operations  to  the  list  of 
archived  operations,  leaving  the  operation  data  in  the  database  unmodified. 

Requirements: 

3.  COA  Sketch  shall  save  system  displays  and  details  of  a  planning  process  to  aid 
the  user  in  re-immersing  themselves  back  into  the  planning  process. 

4.  COA  Sketch  shall  save  system  displays  and  details  of  a  planning  process  to  brief 
or  show  team  members  context  of  the  planning  process. 


Use  Case  3.6:  Open  Archived  Operation 

User  Story  /  Context  of  Use: 

•  After  marking  a  operation  to  be  deleted  and  archived,  a  new  approach  to  an 
existing  operation  might  be  brought  up  in  relation  to  such  operation.  Thus  for 
investigation  the  team  finds  it  necessary  to  load  the  archived  plan  to  see  how  it 
was  previously  implemented. 
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•  After  having  deleted  a  operation  and  archiving  it,  a  team  member  realizes  that 
they  are  not  done  with  the  operation  and  must  reopen  it  for  continued  work. 
Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  A  operation  has  been  archived 
Triggers: 

•  A  team  member  selects  to  restore  a  operation  from  the  archived  operations. 

Guarantees: 

•  The  archived  operation  is  opened  in  the  state  it  was  prior  to  being  archived. 

•  The  operation  is  added  to  the  list  of  available  operations  to  open. 

Main  Success  Scenario: 

1 .  The  user  selects  to  open  an  archived  operation. 

2.  The  system  displays  a  list  of  available  operations. 

3.  The  user  chooses  one  of  the  available  operations. 

4.  The  system  opens  the  selected  operation. 

Requirements: 

3.  COA  Sketch  shall  save  system  displays  and  details  of  a  planning  process  to  aid 
the  user  in  re-immersing  themselves  back  into  the  planning  process. 

5.  COA  Sketch  shall  save  system  displays  and  details  of  a  planning  process  to  brief 
or  show  team  members  context  of  the  planning  process. 


Use  Case  3.21:  Operation  Timing  Storage  (for  future  impiementations) 

User  Story  /  Context  of  Use: 

•  While  determining  the  validity  of  the  timing  of  alpha  days  such  as  C-Day  and  M- 
Day  as  well  as  defining  the  phases  required  as  well  as  each  phase’s  duration,  the 
user  may  wish  to  set  aside  some  determined  timing  data  so  that  it  may  be  referred 
back  to  or  re-set.  This  will  allow  the  user  the  ability  to  play  around  with  dates  and 
timing  without  fear  of  losing  other  potentially  valid  or  useful  timing  data. 

•  The  user  may  wish  to  see  how  the  plan  is  affected  by  using  different  Alpha  Days 
and  Phase  Timing  schemas  that  have  been  pre-determined. 

•  The  user  may  determine  that  a  pre-determined  Alpha  Day  and  Phase  Timing  are 
no  longer  valid  and  should  be  removed  from  the  system. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Team  Member 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  COA  Sketch  is  open. 

•  An  Operation  is  open. 

Triggers: 


B-24 


•  A  team  member  selects  to  store  the  alpha  days  and  phase  timing  for  later  use. 

•  A  team  member  selects  to  set  current  timing  to  reflect  a  stored  timing. 

•  A  team  member  wishes  to  discard  stored  timing  data 

Guarantees: 

•  Alpha  Days  and  phase  timing  will  be  stored  separately  for  the  Operation  Default 

•  Stored  Timing  is  retrieve-able  and  can  be  re-set  as  the  Operation’s  default  timing 

•  Stored  Timing  can  be  removed  from  the  system. 

•  Stored  Timing  Schemas  will  be  stored  as  read  only 

i.  This  is  not  to  be  confused  with  the  Operation’s  T  iming,  which  is  always 

modifiable. 

•  Stored  Timing  will  save  the  following  information  for  later  use: 

i.  mDay  offset  from  D-Day 

ii.  cDay  offset  from  D-Day 

iii.  Other  defined  alpha  days  (future  spiral  implementation) 

iv.  All  Phase  information 
V.  A  User  defined  name 

Main  Success  Scenario  (creating  new  stored  timing): 

1 .  The  user  indicates  to  store  the  current  timing  for  later  use 

2.  The  system  stores  the  data  to  mirror  the  Operation’s  default  timing  information. 

3.  The  system  provides  the  user  a  way  to  modify  the  designated  name  of  the  timing 
information 

4.  The  system  displays  the  newly  stored  information  in  the  list  with  all  other  stored  timing 
information  for  the  Operation 

Alternative  1  (User  selects  to  set  Operation  Timing  to  reflect  a  stored  timing) 

1 .  The  user  selects  to  view  all  the  stored  timing  data. 

2.  The  user  selects  a  stored  timing  to  be  restored. 

3.  The  user  indicates  to  restore  the  selected  stored  timing 

4.  The  system  modifies  the  Operation’s  timing  to  reflect  the  stored  timing 

5.  The  system  removes  existing  Phases  and  creates  new  phases  to  reflect  the  ones  in  the 
stored  timing. 

6.  All  open  displays  will  be  updated  to  reflect  the  changes  selected. 

Alternative  2  (User  chooses  to  delete  a  stored  timing) 

1 .  The  user  selects  to  view  all  the  stored  timing  data. 

2.  The  user  selects  a  stored  timing  to  be  removed  from  the  system 

3.  The  user  indicates  to  delete  the  selected  stored  timing 

4.  The  system  complies. 

5.  The  list  is  updated  to  indicate  that  the  stored  timing  no  longer  exists. 

Use  Case  3.24:  User  specifies  an  Aipha  Day  to  be  used  for  new  timing 
of  elements  in  COA  Sketch  by  default  and  for  use  in  Timing  Views 
(potentiai  future  implementation) 

User  Story  /  Context  of  Use: 
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•  During  the  beginning  stages  of  planning,  the  user  tends  to  use  C-Day  as  the  anchor 
date  for  planning.  Once  the  plan  starts  to  come  to  fruition,  and  D-Day  is  approaching, 
the  user  will  now  wish  to  refer  to  D-Day  as  the  anchor  date  for  planning. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

Triggers: 

•  A  Strategy  Planner  wishes  to  view  offsets  with  respect  to  a  specific  Alpha  Date. 

Guarantees: 

•  The  Synchronization  view  will  be  updated  to  use  the  specified  alpha  Day  with  the 
Gantt  view 

•  The  Plan  Player  will  be  updated  to  display  offsets  in  terms  of  the  specified  Alpha  Day 

•  Any  new  timing  not  currently  bound  to  other  parent  timing  will  reference  the 
specified  Alpha  date  as  the  start  date 

•  (Future  work)  All  timing  currently  referencing  the  old  Specified  date  will  now 
reference  the  new  date  and  offsets  will  be  determined  (i.e.  if  the  offset  was  on  C-Day 
(D-30)  and  was  set  to  be  C  +5,  then  the  specified  alpha  day  was  changed  from  C-Day 
to  D-Day,  then  element’s  timing  would  not  be  D-25.). 

Main  Success  Scenario: 

1 .  User  views  Operation  Timing  Properties. 

2.  System  displays  COA  Timing  properties  to  user. 

3.  User  designates  a  different  Alpha  Day  as  the  “anchor”. 

4.  Views  displaying  general  offset  information  will  use  this  new  Alpha  Day  to  display 
offsets  (Synch  View,  Plan  Player). 

NOTE:  Need  to  update  some  Synch  view  use  cases.  The  synch  view  display  of  timing  should 
not  be  based  upon  d-day  as  the  current  date,  but  should  designate  the  first  day  of  the  first  phase 
as  the  current  date.  (Per  discussion  with  Tim) 

COA  Development 

Use  Case  3.7:  User  creates  a  new  Course  of  Action  (COA) 

User  Story  /  Context  of  Use: 

•  The  JFACC  may  issue  clear  and  specific  guidance  on  how  the  air  COAs  should  vary.  For 
example,  he  may  wish  to  see  the  following  COA  variances  developed: 

•  focused  primarily  on  disrupting  the  strategic  direction  of  the  enemy  armed  forces 
(enemy  strategic  COG); 

•  focused  primarily  on  denying  the  enemy  success  in  his  ground  offensive  (enemy 
operational  COG); 

•  Focused  on  protecting  our  ports  and  forces  (our  operational  COG). 
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•  If  the  JFACC  has  not  specified  how  he  wishes  to  vary  the  air  COAs,  the  Strategy  Division 
should  propose  broad  alternatives  and  obtain  the  JFACC ’s  direction  before  proceeding  to  the 
next  step  in  the  process. 

•  In  general,  air  COAs  may  vary  are  with  respect  to  ends,  ways,  means,  or  risk: 

•  The  ends  that  we  can  vary  are  the  operational  objectives  or  the  degree  to  which 
they  are  achieved. 

•  The  ways  that  we  can  vary  are  the  phase  in  which  an  operational  objective  is 
achieved  as  well  as  the  choice  of  tactical  objectives. 

•  The  means  that  we  can  vary  are  the  level  of  effort  of  kinetic  and  non-kinetic 
resources  that  we  will  apply  to  achieving  the  objectives  and  the  amount  and  type 
of  resources  brought  to  the  conflict. 

•  The  risk  of  success/failure,  force  protection,  or  time  utilized  can  vary;  the  JFC 
and  JFACC  choices  on  these  risks  are  reflected  in  the  combination  of  ends,  ways, 
and  means  of  a  given  COA. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Strategy  Planner,  Strategy  Guidance 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  An  operation  is  open  in  COA  Sketch. 

Triggers: 

•  The  Strategy  Planner  has  completed  Mission  Analysis  and  now  wishes  to  begin  COA 
Development 

•  The  Strategy  Planner  wishes  to  use  the  system  to  aid  in  capturing  COA  Development 
data. 

Guarantees: 

•  A  new  COA  will  be  populated  with  operation  level  defaults  if  any  have  been 
previously  defined. 

o  Timing  Defaults:  By  default,  a  new  COA  will  reference  the  operation  defaults  for 
alpha  days  and  phase  timing.  This  may  be  overridden  in  the  case  that  a  COA 
varies  by  a  difference  in  alpha  days  and  phase  timing. 

•  All  COA  use  operation  level  default  values  but  have  the  additional  attributes  or 
ability  to  have  variant  values  to  the  following  attributes: 

o  A  short  name  or  description 
o  A  long  description  of  the  COA 
o  Mission  Statement 

o  A  distinction  between  “JFACC  Direction”  or  “Ends,  Ways,  Means,  and  Risk” 
o  Indication  of  whether  or  not  operation  default  for  timing  is  used  (by  default,  the 
operation  default  will  be  used) 
o  C-Day  (by  default,  this  is  unused) 
o  M-Day  (by  default,  this  is  unused) 
o  Other  user  defined  alpha-days  (by  default,  this  is  unused) 
o  Phases  (by  default,  this  is  unused) 

■  Title 

■  Duration 
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■  Start  Date 

■  By  default,  the  first  new  phase  will  begin  on  D+0  and  end  24  hours  later. 

All  new  phases  will  by  default  be  added  to  the  end  of  the  phases  and  will 
begin  directly  after  the  last  phase  and  last  24  hours. 

■  Removing  a  Phase: 

•  All  following  phases  will  be  adjusted  to  replace  the  removed 
phase.  If  the  removed  phase  lasted  50  days,  but  began  30  days 
before  the  second  phase,  all  phases  will  be  adjusted  30  days. 

■  Removing  the  last  phase  will  not  result  in  any  changes 
o  Indicators  and  comments  to  indicate  if  a  CO  A  is: 

■  Suitable:  if  it  accomplishes  the  mission 

■  Feasible:  if  it  may  be  accomplished  with  the  available  resources 

■  Acceptable:  if  it  is  within  given  policy  and  guidance  as  well  as  deemed 
worth  the  associated  risks 

■  Complete:  if  it  answers  the  questions:  “Who?”,  “What?”,  “Where?”, 
“When?”,  “Why?”  and  “How?” 

Main  Success  Scenario: 

1 .  The  user  chooses  to  create  a  new  Course  of  Action 

2.  The  system  will  display  the  COA  Editor  allowing  the  user  to  modify  COA  specific 
data.  All  shared  and  editable  fields  will  be  displayed  using  operation  level  default 
values. 

3.  The  user  accepts  changes. 

4.  The  system  will  display  the  new  COA  in  the  appropriate  views  (Synchronization  and 
Sketch  Views) 

Alternative  1  (User  selects  an  existing  COA  as  a  template  for  the  new  one): 

2.  The  user  will  choose  to  use  a  template  for  the  COA. 

3.  The  system  will  display  the  list  of  available  CO  As,  as  well  as  the  choice  to  start  with 
a  blank  one. 

4.  The  user  chooses  an  existing  COA  as  a  template  for  the  new  COA. 

5.  The  system  will  display  the  COA  Editor  allowing  the  user  to  modify  COA  specific 
data.  The  new  COA’s  values  will  be  duplicates  of  the  templated  COA’s  values. 

6.  The  system  will  automatically  apply  the  existing  COAs  plan  elements,  constraints, 
timing,  targets,  relationships,  force  analysis,  phasing  and  sketch  views  to  the  new 
COA.  This  will  create  a  completely  separate  COA  from  the  existing  COA. 

Requirements: 

5.  COA  Sketch  shall  allow  a  user  to  create  COAs. 

Use  Case  3.8:  User  views/Edits  COA  Properties 

User  Story  /  Context  of  Use: 

•  Strategy  Planners  are  responsible  to  develop  COAs  that  are  distinct  from  one  another. 
One  differentiating  factor  can  be  phase  timing,  D-Day,  etc. . .  After  creating  a  particular 
attribute  to  a  COA  the  need  may  arise  for  the  team  member  to  make  adjustments, 
changes  or  report  on  the  values  associated  with  a  particular  COA. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Strategy  Planner,  Strategy  Guidance 
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Supporting  Actors:  CO  A  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  An  operation  is  open  that  has  at  least  one  COA. 

Triggers: 

•  The  Strategy  Planner  has  additional  information  for  a  particular  COA  that  needs  to  be 
represented  in  the  system. 

Guarantees: 

•  The  properties  of  a  COA  as  defined  in  Use  Case  3.7:  User  creates  a  new  Course  of 
Action  (COA) 

Main  Success  Scenario: 

1 .  The  user  chooses  to  view  or  modify  the  properties  of  a  COA. 

2.  The  system  displays  the  COA  property  editor. 

3.  The  user  inputs  the  their  changes  or  simply  views  the  data  and  indicates  completion 
of  the  operation.. 

4.  The  system  persists  the  changes  to  the  COA  and  closes  the  editor. 

Alternative  1  (User  modifies  a  COA  that  has  been  designated  as  a  Plan): 

1.  Follow  steps  1-3  as  Main  Success  Scenario. 

2.  The  system  persists  the  changes. 

5.  The  system  sets  the  values  of  the  Plan  to  be  the  default  Operation  level  values.  For  a 
listing  of  the  data  see  use  case  “User  Modifies  Operation  Details”  guarantee  section. 

Alternative  2  (User  modifies  a  COA’s  timing  to  be  different  than  operation  default): 

1.  Follow  steps  1-2  in  Main  Success  Scenario. 

2.  User  chooses  to  enter  in  alpha  days  and  phases  specific  only  to  this  COA  and  not  use 
the  operation’s  default  values. 

3.  The  system  checks  for  existing  timing  elements  contained  within  the  COA  that  uses 
the  operation’s  default  data.  If  timing  elements  exist,  The  system  warns  the  user  that 
this  timing  information  will  now  reference  the  new  timing  information. 

a.  If  User  cancels,  no  modifications  to  timing  will  take  place.  Return  to  step  3  of 
the  Main  Success  Scenario. 

b.  If  user  accepts,  continue  to  step  4. 

4.  The  system  persists  this  choice  and  creates  a  new  C-Day  and  M-Day  for  the  COA  and 
displays  this  data  to  the  user.  The  Operation  will  always  contain  a  single  D-Day  that 
is  reference  by  all  COAs. 

i.  C-Day  and  M-Day  will  be  set  to  mirror  the  Operation’s  default  C-Day  and 
D-Day  timing 

ii.  All  existing  timing  elements  will  be  mapped  to  use  these  alpha  days 
instead  of  the  operation  default. 

hi.  If  the  Operation  has  default  phases,  then  the  COA  will  by  default  also  be 
set  up  with  Phases  that  mirror  the  Operation’s. 

6.  The  system  will  display  the  new  timing  choices  for  the  user  to  be  able  to  view/modify 

7.  Return  to  step  3  of  Main  Success  Scenario. 

Alternative  3  (User  modifies  a  COA’s  timing  from  individually  defined  to  use  the 
operation  default): 

1.  Follow  steps  1-2  in  Main  Success  Scenario. 
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2.  The  user  chooses  to  use  the  Operation’s  default  alpha  days  and  phases  instead  of 
using  the  COA’s  defined  timing. 

3.  The  system  checks  for  existing  timing  elements  contained  within  the  CO  A  that  uses 
the  COA’s  timing  data.  If  timing  elements  exist,  The  system  warns  the  user  that  this 
timing  information  will  now  reference  the  operation’s  default  timing. 

a.  If  User  cancels,  no  modifications  to  timing  will  take  place.  Return  to  step  3  of 
the  Main  Success  Scenario. 

b.  If  user  accepts,  continue  to  step  4. 

4.  The  system  will  update  the  CO  A  so  that  it  references  the  operation’s  default.  The 
system  will  update  all  existing  timing  elements  for  the  COA  to  be  mapped  using  the 
alpha  days  and  phases  established  as  the  operation  default. 

5.  The  system  will  display  to  the  user  that  the  operation  default  timing  is  now  being 
used. 

6.  Return  to  step  3  of  the  Main  Success  Scenario. 

Requirements: 

6.  COA  Sketch  shall  allow  the  user  to  Edit  COAs. 

Use  Case  3.9:  User  deletes  a  COA 

User  Story  /  Context  of  Use: 

•  After  initial  strategic  planning  and  creation  of  several  COAs,  during  evaluation  of 
distinguishability  of  a  particular  COA  from  another  the  Strategy  Planner  has 
determined  a  COA  is  not  feasible,  suitable,  acceptable,  distinguishable  or  complete 
enough  to  warrant  continued  development  and  thus  no  longer  needed  in  the  system. 

•  When  creating  the  initial  set  of  COAs  a  user  unintentionally  creates  a  COA  in  the 
system  beyond  the  number  they  were  asked  to  prepare  and  they  wish  to  remove  said 
superfluous  COA  from  the  system. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Strategy  Planner,  Strategy  Guidance 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  An  operation  is  open  that  has  at  least  one  COA. 

Triggers: 

•  The  Strategy  Planner  determines  that  a  particular  COA  is  no  longer  needed. 

Guarantees: 

•  The  COA  is  removed  from  the  operation. 

•  Deleting  any  COA  will  not  affect  the  operation’s  default  timing. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  delete  a  COA. 

2.  The  system  prompts  the  user  to  confirm  delete  COA. 

3.  The  user  confirms  the  deletion  of  the  COA. 
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4.  The  system  determines  all  the  COA  and  related  data  to  remove,  including  all  links  to 
it  in  the  operation.  If  the  COA  contained  elements  that  were  created  in  support  of 
other  Courses  of  Action,  then  it  removes  the  reference  to  that  data,  but  leaves  the 
element  untouched. 

5.  The  system  purges  all  of  the  data  determined  for  deletion. 

Alternative  1  (User  cancels  delete): 

1 .  The  user  chooses  to  delete  a  COA. 

2.  The  system  prompts  the  user  to  confirm  delete  COA. 

3.  The  user  cancels  the  deletion  of  the  COA. 

6.  The  system  reverts  to  its  former  state. 

Alternative  1  (User  deletes  a  COA  that  contains  elements  reference  by  other  COAs): 

1.  Follow  steps  1-4  of  Main  Success  Scenario 

2.  The  system  determines  that  a  COA  element  that  directly  supports  the  COA  marked 
for  deletion  is  referenced  by  another  COA(s). 

3.  The  system  prompts  the  user  to  choose  to  delete  the  COA  or  to  choose  one  of  the 
reference  COAs  as  the  element’s  new  COA  to  directly  support. 

a.  The  user  chooses  to  delete  the  element. 

i.  The  system  adds  the  element  and  its  children  to  the  data  to  be  purged 
by  the  system 

ii.  Return  to  step  5  of  the  main  success  scenario. 

b.  The  user  chooses  to  have  the  element  directly  support  a  different  COA 

i.  The  system  modifies  the  element  and  any  child  element  that  directly 
supports  the  COA  selected  for  deletion.  These  elements  will  now 
directly  support  the  COA  that  the  user  selected. 

ii.  The  system  will  skip  this  element  and  its  children  in  the  deletion 
process. 

iii.  Return  to  Step  4  of  the  main  success  scenario. 


Requirements: 

6.  COA  Sketch  shall  allow  the  user  to  Edit  COAs. 

Use  Case  3.10:  User  checks  the  validity  of  each  COA:  Suitable, 
Feasible,  Acceptable,  Distinguishable  and  Complete 

User  Story  /  Context  of  Use: 

•  As  a  planner  is  developing  a  COA  they  should  be  evaluating  each  as  being  suitable, 
feasible,  acceptable,  distinguishable  and  complete. 

•  After  a  COA  has  been  completed  and  is  being  evaluated  and  presented  it  would  be 
useful  to  point  to  the  evaluation  criteria  and  comments  associated  with  each  evaluation 
point. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Strategy  Planner,  Strategy  Guidance 
Supporting  Actors:  COA  Sketch 
Preconditions: 
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•  COA  Sketch  is  open. 

•  An  operation  is  open  that  has  at  least  one  COA. 

Triggers: 

•  The  Strategy  Planner  has  progressed  into  development  to  the  point  of  checking  the  COA 
for  suitability,  feasibility,  acceptability,  distinctness  and  completeness. 

Guarantees: 

•  To  evaluate  the  validity  of  each  COA  there  are  five  criteria  for  a  COA  to  be  considered 
“valid”.  JP  3-30  (p.  III-l  1)  says,  "Planners  determine  the  validity  of  each  COA  based 
on  suitability,  feasibility,  acceptability,  distinguishability,  and  completeness.” 

•  The  evaluation  view  will  provide  for  inputs  on  the  below  listed  points,  and  comments 
associate  with  the  field  for  who,  what,  when,  where,  why,  and  how. 

•  A  COA  is: 

■  suitable  if  it  accomplishes  the  mission; 

■  feasible  if  it  may  be  accomplished  with  resources  available; 

■  acceptable  if  it  is  within  given  policy  and  guidance  and  worth  the  risks; 

■  distinguishable  if  it  is  significantly  different  from  other  CO  As;  and 

■  complete  if  it  answers  the  questions:  who,  what,  where,  when,  why,  and  how. 
Main  Success  Scenario: 

1 .  The  user  chooses  to  evaluate  a  COA. 

2.  The  system  displays  the  evaluation  view. 

3.  The  user  inputs  the  evaluation  of  the  COA  and  accepts  changes. 

4.  The  system  persists  the  changes  to  the  evaluation  and  closes  the  view. 

Requirements: 


7.  COA  Sketch  shall  provide  user  with  a  way  to  validate  CO  As  based  on  Suitable, 
Feasible,  Acceptable,  Distinguishable,  and  Complete. 


Use  Case  3.11:  Designate  COA  as  Plan 

User  Story  /  Context  of  Use: 

•  After  the  preliminary  COA  development  and  an  evaluation  of  the  CO  As  the  Strategy 
Planners  will  decide  on  a  particular  COA  that  will  be  the  Plan  for  the  operation,  and 
thus  further  fleshed  out. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  A  operation  is  open  with  at  least  one  COA. 

Triggers:  User  wishes  to  mark  a  particular  COA  as  a  Plan  for  the  operation. 

Guarantees: 

•  Updates  operation  wide  default  data  to  reflect  all  values  of  the  designated  COA.  Through  this 
designation  all  values  that  are  shared  between  COAs  and  Operation  level  defaults  will  be  set  to 
have  the  same  value  of  the  designated  plan.  All  other  COAs  will  retain  all  the  values  they 
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currently  have  even  if  they  were  populated  by  operation  defaults,  as  if  they  had  overridden  the 
operation  defaults  when  ereated. 

Main  Success  Scenario: 

•  User  decides  to  designate  a  COA  as  a  Plan  for  the  operation. 

•  System  marks  COA  as  Plan. 

•  All  operation  data  specific  to  the  COA  is  eonsidered  default  data  to  the  operation.  For 
listing  of  such  data,  see  use  ease  “User  Modifies  Operation  Details”  guarantee  seetion. 

Requirements: 

6.  COA  Sketeh  shall  allow  the  user  to  Edit  CO  As. 

Use  Case  3.12:  Revert  Plan  to  COA 

User  Story  /  Context  of  Use: 

•  After  the  preliminary  designating  a  partieular  COA  as  a  plan,  it  might  be  necessary 
after  seeing  further  development,  to  wish  to  speeify  that  this  particular  approach  is  no 
longer  feasible/desirable  for  whatever  reason.  The  user  would  like  to  make  the 
previously  marked  plan  as  a  regular  COA. 

Scope:  User  to  COA  Sketeh  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  A  operation  is  open  that  has  at  least  one  COA. 

Triggers:  User  wishes  to  mark  a  partieular  COA  as  a  Plan  for  the  operation. 

Guarantees: 

•  Operation  default  values  are  left  as  they  last  were  indicated.  Most  likely  the  values  that  were 
inherited  on  the  last  modifieation  of  the  former  plan  or  the  values  the  COA  held  when  it  was 
marked  as  a  Plan. 

Main  Success  Scenario: 

•  User  decides  to  revert  a  plan  to  COA  status. 

•  System  marks  Plan  as  a  COA. 

•  All  operation  data  specific  to  the  COA  is  eonsidered  default  data  to  the  operation.  All 
operation  data  specific  to  the  COA  is  left  as  it  were  and  is  treated  as  it  would  in  being  a 
COA.  For  listing  of  sueh  data,  see  use  case  “User  Modifies  Operation  Details” 
guarantee  seetion. 

Requirements: 

6.  COA  Sketeh  shall  allow  the  user  to  Edit  CO  As. 

Use  Case  3.20:  User  specifies  that  COA  Timing  will  be  used  as 
Operation  Default 

User  Story  /  Context  of  Use: 
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•  The  user  has  created  a  new  Course  of  Action  or  Plan  and  has  set  Alpha  Days  and 
Phasing  information  that  was  specific  to  the  CO  A/Plan  only.  However,  the  user  has 
determined  that  it  would  be  beneficial  to  have  all  Courses  of  Action  at  all  levels  of 
war  to  also  use  the  same  Alpha  Days  and  Phasing  as  this  CO  A/Plan  by  default.  The 
user  may  wish  to  replace  the  timing  for  the  whole  operation,  or  just  use  the  Course  of 
Action’s  timing  directly.  By  replacing  the  timing  of  the  operation,  it  will  allow  the 
user  to  still  maintain  the  Course  of  Action’s  ability  to  manipulate  timing  without  it 
being  reflected  throughout  the  system.  If  the  user  determines  to  use  the  COA’s  timing 
directly,  then  the  user  anticipates  that  the  COA’s  timing  changes  should  also  be 
reflected  throughout  the  system  as  well. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Strategy  Planner 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  COA  Sketch  is  open. 

•  At  least  one  COA  has  been  created.  The  COA  is  not  using  the  operation’s  default 
timing  elements. 

Triggers: 

•  A  Strategy  Planner  wishes  that  all  default  timing  for  new  and  existing  CO  As  are  now 
based  upon  the  same  timing  as  an  existing  COA. 

Guarantees: 

•  The  Alpha  days  for  the  operation  default  will  be  the  same  as  the  selected  COAs. 

•  The  selected  COA  will  now  be  displayed  as  using  the  operation  default. 

•  All  COAs,  Mission  Analysis  timing,  and  Plan  Player  comments  will  be  updated  to 
reflect  the  change  in  Alpha  Days. 

Main  Success  Scenario: 

1 .  User  views  Operation  Timing  Properties. 

2.  User  chooses  to  change  the  Operation’s  timing  properties  to  be  the  same  as  a  COA 
that  has  its  own  defined  timing. 

3.  The  system  warns  the  user  that  all  existing  Mission  Analysis,  Player  Comments,  and 
COA  Planning  Elements  will  be  affected  by  the  change. 

■  If  User  cancels,  no  modifications  to  timing  will  take  place.  Return  to  step 
3  of  the  Main  Success  Scenario. 

■  If  user  accepts,  continue  to  step  4. 

4.  The  system  updates  the  Operation’s  default  timing  to  reflect  the  same  timing  on  the 
selected  COA. 

5.  The  system  updates  the  COA  to  indicate  that  it  is  now  using  the  operation’s  default. 

7.  The  system  updates  displays  to  adjust  timing  elements  and  the  display  of  Phase 

information  that  are  using  the  operation’s  defaults. 

Alternative  1  (User  chooses  to  directly  use  COA  Timing  over  Operation’s  timing): 

1 .  User  views  Operation  Timing  Properties. 

2.  User  chooses  to  change  the  Operation’s  timing  properties  so  that  it  references  a 
Course  of  Action’s  specified  timing 

3.  The  system  displays  the  COAs  that  have  specified  timing  to  the  user. 

a.  The  user  chooses  a  COA. 
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b.  The  system  warns  the  user  that  all  existing  Mission  Analysis,  Player 
Comments,  and  COA  Planning  Elements  will  be  affected  by  the  change. 

i.  If  User  cancels,  no  modifications  to  timing  will  take  place. 

ii.  If  user  accepts,  continue  to  step  4. 

4.  The  system  updates  the  display  to  indicate  that  the  chosen  COA’s  timing  is  used  as 
default  for  the  operation. 

The  system  updates  the  timing  in  the  displays  in  reaction  to  the  timing  and  phase  updates. 


Use  Case  3.22:  User  specifies  a  specific  date  for  D-Day  of  a  Course  of 
Action 

User  Story  /  Context  of  Use: 

•  Sometime  during  the  planning  process,  the  Alpha  Dates  actual  dates  may  be 
determined.  In  this  case,  the  user  will  need  to  be  able  to  apply  actual  dates  so  that 
they  may  analyze  how  the  plan  will  work  within  the  actual  dates  that  have  been  given. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Strategy  Planner 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  COA  Sketch  is  open. 

•  At  least  one  COA  has  been  created.  The  COA  is  not  using  the  operation’s  default 
timing  elements. 

•  If  changing  Operation’s  Default  timing  for  D-Day,  then  Operation  must  be  utilizing 
its  own  default  timing  and  not  referencing  another  COA’s  timing. 

Triggers: 

•  A  Strategy  Planner  needs  to  set  D-Day  to  a  specific  date. 

Guarantees: 

•  All  dates  that  are  relative  to  the  COA’s  D-day  (all  dates  within  the  COA)  will  be 
displayed  relative  to  the  new  D-Day’s  position 

•  Views  displaying  date  information  may  now  be  configured  to  display  actual  date 
information. 

•  All  Courses  of  Action  not  using  an  actual  date  will  have  D-Day  be  displayed  as  the 
current  date. 

Main  Success  Scenario: 

1 .  User  views  COA  Timing  Properties. 

2.  System  displays  COA  Timing  properties  to  user. 

3.  User  chooses  to  edit  the  D-Day  properties 

4.  The  system  displays  D-Day  properties  to  user. 

5.  The  user  indicates  the  actual  date  (Month,  Day,  and  year)  for  D-Day. 

6.  The  system  stores  the  values  and  updates  displays  that  display  timing  information  to 
reflect.  If  a  specified  date  has  not  been  set  on  the  Operation’s  default  or  any  other 
COA  using  specified  timing,  then  the  default  position  that  these  dates  will  be 
displayed  at  will  include  D-Day  being  the  current  date.  Note:  This  date  is  not  stored, 
so  the  next  time  the  user  opens  the  system,  the  unspecified  D-Day  will  always  be 
displayed  on  the  current  date 
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Alternative  1  (User  chooses  to  dismiss  the  use  of  specifying  an  actual  date  for  D-Day 
and  leave  it  as  unspecified): 

1.  Follow  steps  1-4  of  the  main  sueeess  scenario. 

2.  The  user  indicates  to  no  longer  use  an  actual  date  for  D-Day. 

3.  The  system  determines  if  the  Operation  Default  or  any  other  CO  A  is  using  an  actual 
date  for  D-Day. 

a.  If  not,  the  system  will  update  views  so  that  the  actual  date  information  is 
hidden.  The  system  will  align  all  D-Days  throughout  the  system  to  be  on  the 
same  day  and  update  the  view  of  the  plan  data  to  reflect  this. 

b.  If  so,  then  the  system  will  align  the  D-Day  for  the  selected  COA  to  be  on  the 
current  date.  Note:  This  date  is  not  stored,  so  the  next  time  the  user  opens  the 
system,  the  unspecified  D-Day  will  always  be  displayed  on  the  current  date. 

Alternative  2  (User  chooses  to  set  an  actual  date  for  the  Operation’s  Default  D-Day): 

1 .  User  views  Operation  Default  Timing  Properties. 

2.  System  displays  Operation  Default  Timing  properties  to  user. 

3.  See  steps  3-  5  of  main  success  scenario. 

4.  The  system  stores  the  values  and  updates  displays  that  display  timing  information  to 
reflect,  including  all  Plan  Player  comments,  Mission  Analysis  timing,  and  any  COA 
timing  that  is  using  the  default  dates.  If  a  specified  date  has  not  been  set  on  any  other 
COA  using  specified  timing,  then  the  default  position  that  these  dates  will  be 
displayed  at  will  include  D-Day  being  the  current  date.  Note:  This  date  is  not  stored, 
so  the  next  time  the  user  opens  the  system,  the  unspecified  D-Day  will  always  be 
displayed  on  the  current  date 

Alternative  4  (User  chooses  to  unset  use  of  an  actual  date  for  the  Operation’s  Default  D- 
Day): 

1 .  User  views  Operation  Default  Timing  Properties. 

2.  System  displays  Operation  Default  Timing  properties  to  user. 

3.  See  steps  3-  4  of  main  success  scenario. 

4.  The  user  indicates  to  no  longer  use  an  actual  date  for  D-Day. 

5.  The  system  determines  any  other  COA  is  using  an  actual  date  for  D-Day. 

a.  If  not,  the  system  will  update  views  so  that  the  actual  date  information  is 
hidden.  The  system  will  align  all  D-Days  throughout  the  system  to  be  on  the 
same  day  and  update  the  view  of  the  plan  data  to  reflect  this. 

b.  If  so,  then  the  system  will  align  the  D-Day  for  the  selected  COA  to  be  on  the 
current  date.  Note:  This  date  is  not  stored,  so  the  next  time  the  user  opens  the 
system,  the  unspecified  D-Day  will  always  be  displayed  on  the  current  date. 


Use  Case  3.23:  User  designates  an  Alpha  Hour  for  an  Alpha  Day 

User  Story  /  Context  of  Use: 

•  The  user  may  wish  to  designate  what  time  1-hour  is  for  C-Day,  or  other  designated 
Alpha  Days. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
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Preconditions: 

•  COA  Sketch  is  open  and  an  Operation  is  open. 

•  In  the  case  of  designating  for  a  COA  using  specific  timing,  then  there  must  be  a  COA 
that  is  using  specific  timing  instead  of  the  Operation’s  default. 

Triggers: 

•  A  Strategy  Planner  needs  to  set  at  what  hour  the  alpha  day  should  begin  and  designate 
a  lowercase  character  for  it. 

Guarantees: 

•  All  dates  that  are  relative  to  the  Alpha  Day  and  displayed  in  any  current  views  will  be 
updated  to  reflect  the  change  or  designation  of  an  alpha  hour. 

Main  Success  Scenario: 

1 .  User  views  COA  or  Operation  Timing  Properties. 

2.  System  displays  COA  or  Operation  Timing  properties  to  user. 

3.  The  user  chooses  to  view  the  specific  properties  of  an  Alpha  Day. 

4.  The  system  displays  those  properties. 

5.  The  user  chooses  to  assign  an  alpha  hour  to  the  Alpha  Day. 

6.  The  system  provides  the  user  the  ability  in  select  or  input  a  lowercase  character  to 
designate  the  alpha  day.  If  the  Alpha  day  has  a  default  designation,  this  is  chosen  for 
the  user  as  a  suggestion. 

7.  The  user  chooses  the  character  to  assign  to  the  alpha  hour. 

8.  The  system  checks  the  timing  scheme  to  see  if  the  alpha  hour’s  time  has  already  been 
designated  for  the  Operation  Default  or  the  COA’s  specified  timing,  depending  upon 
which  timing  scheme  the  user  is  editing.  If  it  has,  then  it  will  display  the  designated 
time.  Otherwise,  it  will  display  a  designated  default  time. 

9.  The  user  may  edit  the  timing  of  the  alpha  hour  (hour,  minute,  second,  millisecond). 

10.  The  system  will  update  the  views  to  project  the  change  in  offsets  of  the  values 
referencing  the  Alpha  Day.  If  an  alpha  hour  had  not  been  set  yet,  then  the  system 
would  have  used  a  designated  time  as  default  (this  is  a  System-level  capability  that  is 
not  displayed  to  the  user).  This  time  is  replaced  by  the  new  alpha  hour  timing.  If  the 
alpha  hour  was  designated  to  be  used  by  another  alpha  day,  then  modifications  to  the 
alpha  hour  will  also  cause  the  system  to  update  the  views  to  project  the  change  in 
offsets  of  the  values  referencing  the  other  affected  alpha  days  as  well. 


COA  Sketch  Object  Use  Cases 

Use  Case  3.13:  Create  Strategy  Object  or  Generic  Object 

User  Story  /  Context  of  Use: 

•  After  creating  a  new  COA,  or  gathering  more  intelligence  associated  with  a  developing 
COA,  a  Strategy  Planner  will  need  to  have  this  information  reflected  as  an  action, 
intelligence  or  indicator.  This  can  be  the  initially  provided  data  on  the  situation  or 
additional  information  from  a  TET  Liaison,  MAAP  Liaison  or  other  another  team 
member.  The  user  will  need  to  be  able  to  add  this  information  into  the  COA. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Strategy  Planner,  TET  Liaison 
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Supporting  Actors:  CO  A  Sketch 
Preconditions: 

5.  CO  A  Sketch  is  open. 

6.  A  operation  is  open  with  at  least  one  COA. 

7.  A  view  in  which  COA  Sketch  elements  are  selectable  is  open. 

8.  The  plan  has  at  least  one  COA  Sketch  element. 

9.  If  modifying  causal  links,  a  COA  or  plan  has  at  least  two  plan  elements  where  one 
plan  element  is  a  linked  to  the  other. 

Triggers: 

10.  A  Strategy  Planner  needs  to  enter  an  action,  Operational  Objective,  Tactical 
Objective,  Tactical  Task,  etc. . .  for  a  COA 

Guarantees: 

•  Changes  to  the  strategy  object  will  be  persisted.  The  following  are  the  types  of 
Strategy  Objects  in  the  system: 

o  National  Objectives 
o  National  Task 
o  National  Activity 
o  Strategic  Objectives 
o  Strategic  Tasks 
o  Strategic  Activity 
o  Operational  Objectives 
o  Operational  Tasks 
o  Operational  Activity 
o  Tactical  Objective 
o  Tactical  Tasks 
o  Tactical  Activity 

•  Every  Strategic  Object,  Generic  Object  or  Assessment,  referred  to  as  a  COA  Sketch 
Object,  has  the  following  attributes  that  can  be  modified  by  the  user: 

o  Short  name 
o  Description 
o  Affiliation 

■  Friendly/Neutral/Adversarial 
o  Visual  Characteristics 

■  Border  Thickness 

■  Color 

■  Transparency 

o  Timing  information  (by  default,  this  data  is  not  filled  out) 

■  Start 

■  Stop 

■  Start  no  earlier  than 

■  Stop  no  later  than 
o  Map  data 

o  Dependencies 

■  Only  viewed  and  removed  in  property  editor 
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o  Causal  links  for  Strategy  Objects  related  to  one  another,  Connections  of  an 
Assessment  Object  to  a  Strategy  Object,  and  Connections  of  Generic  Objects  to 
other  Generic  Objects  or  Strategy  Objects, 
o  Logging  information 

■  Creation  Date 

■  Creator  (like  username  of  the  creator) 

■  Modification  Date* 

■  Modifier* 

*  For  each  modification 

•  Strategy  Objects  have  all  previous  information  except  affiliation  as  well  as: 
o  ID  Field 

o  Priority 

o  Targeting  Information 
o  Links  to  Parents/Child(ren) 

■  These  are  causal  links  that  have  a  label/explanation 
o  Benefit 

■  Name 

■  Description 

■  Value 

•  High/Medium/Low 

o  Comment(s) 
o  Weight  of  effort 

■  High/Medium/Low 

•  Definition  of  what  classifies  as  such  to  be  determined  in  SAAP  uses 
cases. 

•  Changes  to  Strategy  Objects  will  be  reflected  in  all  applicable  views.  These  changes 
include  but  are  not  limited  to  timing  constraints,  hierarchal  relationships 
(parent/child)  will  be  modified  properly,  alterations  to  other  elements  because  of 
constraints  (timing,  etc. . .),  targeting  allocation  in  the  allocation  view,  etc. . . 

•  Time  sensitive  attr  ibutes,  or  attr  ibutes  th  at  eh  ange  over  th  e  course  of  a  Stra  tegy 

Object,  will  be  recorded  and  reflected  in  the  views  in  which  such  changes  are 
represented.  As  well,  the  history  of  such  attributes  will  be  stored  and  viewable.  E.g. 
For  the  Operational  O  bjective  “M  aintain  Air  Superiority”  for  phase  one  becom  es 
“Gain  and  Maintain  Air  Superiority”  in  phase  2,  both  names  are  clearly 

distinguishable  for  the  time  frames  in  which  they  are  in  effect. 

•  Changes  to  Strategy  Objects  will  adjust  related  objects  based  on  known  and  implied 
constraints,  such  as  targets  moving  out  of  range,  and  impacts  to  all  applicable  views 
because  of  such  adjustments  will  be  updated. 

•  Tagging  data  objects  that  are  displayed  upon  the  map  will  allow  the  team  member  to 
easily  hide/show  the  information  based  upon  a  user  defined  tag. 

•  Allowing  the  user  to  create  a  hierarchy  of  tagging  elements  will  better  allow  them  to 
organize  and  categorize  data  in  multiple  useful  ways.  This  will  allow  for  easier 
access  to  associated  data  based  upon  the  way  the  user  and  team  works. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  create  a  Strategy  Object  or  generic  object. 


B-39 


2.  The  system  prompts  the  user  for  information  pertaining  to  the  element  or  objeet  being 
created  (see  guarantees  for  required  data). 

3.  The  user  accepts  the  changes. 

4.  The  system  persists  the  data  and  updates  all  relevant  views. 

Alternative  2  (User  creates  an  element  using  another  as  a  template ): 

2.  The  user  indicates  to  use  another  element  as  a  template. 

3.  The  system  prompts  the  user  for  information  pertaining  to  the  element  or  object  being 
created,  pre-populating  the  fields  with  the  data  from  the  template  element/object. 

4.  Follow  steps  3-4  of  the  Main  Success  Scenario. 

Alternative  3  (User  cancels  add  new  Strategy  Object  or  Generic  Object): 

4.  The  user  decides  to  cancel  the  creation  of  the  element  or  object. 

5.  The  system  reverts  to  its  state  prior  to  invoking  the  creation. 

Requirements: 

8.  c 

Use  Case  3. 14:  View/Modify  Strategy  Object’s  or  Generic  Object’s 
Properties 

User  Story  /  Context  of  Use: 

11.  As  a  plan  becomes  more  refined,  it  is  important  that  the  team  member  keeps  track  of 
these  refinements  and  has  the  ability  to  make  changes  over  time.  As  well  input  from  a 
TET  Liaison,  team  member  or  MAAP  Liaison  might  need  to  be  reflected.  These 
changes  will  be  important  to  the  situational  awareness  of  the  team  and  also  important 
to  the  overall  completeness  of  the  COA/JAOP/AOD  that  is  currently  being  planned  or 
re-planned.  COA  Sketch  will  also  be  able  to  aid  the  Strategy  Planner  in  re-allocation 
issues  due  to  changes  made  to  targets  or  timing  information  in  the  element  properties 
induced  by  these  changes  made  to  a  Strategy  Object. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Strategy  Planner,  TET  Liaison 

Supporting  Actors:  COA  Sketch 

Preconditions: 

12.  COA  Sketch  is  open. 

13.  An  operation  is  open  that  has  at  least  one  COA. 

14.  A  view  in  which  COA  Sketch  elements  are  selectable  is  open. 

15.  The  plan  has  at  least  one  COA  Sketch  element. 

16.  If  modifying  causal  links,  a  COA  or  plan  has  at  least  two  plan  elements  where  one 
plan  element  is  a  linked  to  the  other. 

17.  The  target  type  or  category  must  exist  within  the  systems  providing  target  data. 

18.  To  view  target  data  associated  with  a  plan  element,  a  COA  needs  to  be  open  with  at 
least  one  plan  element  that  has  targets  associated  with  it. 

19.  To  view  targeting  data,  COA  Sketch  has  a  connection  to  the  Targeting  database 

Triggers: 

20.  User  needs  to  view  or  modify  properties  of  a  Strategy  or  Generic  Object. 

Guarantees: 

•  Changes  to  the  Strategy  or  Generic  Object  will  be  persisted. 
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•  The  types  of  strategy  objects  are  as  defined  in  use  case  7.9:  Create  Strategy  Object  or 
Generic  Object 

•  Every  Strategy  or  Generic  Object  has  the  attributes  as  defined  in  use  case  7.9:  Create 
Strategy  Object  or  Generic  Object. 

•  Changes  to  Strategy  Objects  will  be  reflected  in  all  applicable  views.  These  changes 
include  but  are  not  limited  to  timing  constraints,  relationships  (parent/child)  will  be 
modified  properly,  alterations  to  other  elements  because  of  dependencies  (timing, 
etc. . .),  targeting  allocation  in  the  allocation  view,  etc. . . 

•  Time  sensitive  attr  ibutes,  or  attr  ibutes  th  at  ch  ange  over  th  e  course  of  a  Stra  tegy 

Object,  will  be  recorded  and  reflected  in  the  views  in  which  such  changes  are 
represented.  As  well,  the  history  of  such  attributes  will  be  stored  and  viewable.  E.g. 
For  the  Operational  O  bjective  “M  aintain  Air  Superiority”  for  phase  one  becom  es 
“Gain  and  Maintain  Air  Superiority”  in  phase  2,  both  names  are  clearly 

distinguishable  for  the  time  frames  in  which  they  are  in  effect. 

•  Changes  to  Strategy  Objects  will  adjust  related  objects  based  on  known  and  implied 
constraints,  such  as  targets  moving  out  of  range,  and  impacts  to  all  applicable  views 
because  of  such  adjustments  will  be  updated. 

•  Tagging  data  objects  that  are  displayed  upon  the  map  will  allow  the  team  member  to 
easily  hide/show  the  information  based  upon  a  user  defined  tag. 

•  Allowing  the  user  to  create  a  hierarchy  of  tagging  elements  will  better  allow  them  to 
organize  and  categorize  data  in  multiple  useful  ways.  This  will  allow  for  easier 
access  to  associated  data  based  upon  the  way  the  user  and  team  works. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  modify  a  Strategy  Object  or  generic  object. 

2.  The  system  enables  the  editing  options  for  the  selected  element  or  object. 

3.  The  user  performs  edits  on  or  views  the  properties  of  the  object. 

4.  The  user  indicates  they  are  finished  making  changes. 

5.  The  system  persists  the  changes. 

Requirements: 

2.  COA  Sketch  shall  allow  the  user  to  edit  and  save  the  current  planning  process 

information. 


Use  Case  3.15:  Convert  COA  Sketch  Object  to  a  different  type  of  COA 
Sketch  Object. 


User  Story  /  Context  of  Use: 

•  Throughout  the  COA  Analysis  process,  the  user  may  determine  that  an  Operational 
Objective  is  actually  a  Tactical  Objective  or  vice  versa.  The  Strategy  Planner  may 
have  used  Generic  Objects  to  represent  generic  actions  and  is  now  ready  to  further 
refine  the  plan  to  determine  the  type  of  plan  object  that  it  should  represent. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 
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•  COA  Sketch  is  open. 

•  A  operation  is  open  that  has  at  least  one  COA. 

•  A  COA  Sketch  Object  exists. 

Triggers:  Strategy  Planner  wishes  to  refine  plan  element  type. 

Guarantees: 

•  User-defined  Sketch  Object  will  take  on  characteristics  of  chosen  object  type.  For  example,  if 
a  user  conv  erts  a  Generic  Object  to  a  Strategy  Object,  the  object  will  now  have  all  the  fields 
associated  with  Strategy  Objects.  As  well,  if  a  Strategy  Object  is  changed  to  a  Generic  Object 
all  fields  not  shared  between  the  two  types  will  be  lost. 

•  Relationships  to  other  plan  elements  will  be  handled  cautiously. 

Main  Success  Scenario: 

•  The  user  chooses  to  convert  an  object  to  a  different  type  by  selecting  the  object  and 
activating  the  object  editor. 

•  The  system  will  display  the  object  editor  with  data  from  the  current  object. 

•  The  user  can  change  the  object’s  properties  in  the  object  editor. 

•  The  user  indicates  to  save  the  changes. 

•  The  system  will  store  the  changes  and  update  all  affected  views,  as  well  as  informing 
other  users  of  the  change. 

Requirements: 

8.  COA  Sketch  shall  provide  users  a  way  to  create/modify  data  associated  with  a  COA  or  Plan. 


Use  Case  3.16:  Create  Assessment  Object 

User  Story  /  Context  of  Use: 

•  The  Operational  Assessment  Team  requires  Measures  and  Indicators  in  order  to 
assess  the  performance  and  achievement  of  effects.  To  be  able  to  capture  and 
represent  this,  the  user  wishes  to  associate  a  measure  or  indicator  with  a  particular 
Strategy  Object. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  An  operation  is  open  that  has  at  least  one  COA. 

•  A  Strategy  Object  exists. 

Triggers:  User  wishes  to  add  a  new  measure  or  indicator  associated  with  a  Strategy  Object. 

Guarantees: 

•  Assessment  objects  can  be  of  the  following  types: 

o  Measure  of  Effectiveness  (MoE) 
o  Measure  of  Performance  (MoP) 
o  Indicator 

•  Assessment  objects  represent  the  following  data: 

o  Related  Strategy  Object 
o  Related  Effect(s) 
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o  Explanation/comment  for  the  relationship/link  to  the  related  effeets. 
o  A  status/assessment  field  to  indieate  the  level  of  aehieve  measure. 

•  A  partieular  assessment  object  will  only  relate  to  one  Strategy  Object,  but  could  be  associated 
with  several  desired  effects  of  that  Strategy  Object. 

Main  Success  Scenario: 

•  User  elects  to  associate  an  assessment  object  to  a  particular  Strategy  Object. 

•  The  system  prompts  the  user  for  data  relating  to  the  assessment  object,  including  which 
effects  of  the  Strategy  Object  it  should  relate  to. 

•  The  user  enters  relevant  data  and  confirms  the  changes. 

•  The  system  persists  the  changes. 

Requirements: 

8.COA  Sketch  shall  provide  users  a  way  to  create/modify  data  associated  with  a  COA  or  Plan. 

Use  Case  3.17:  View/Modify  Assessment  Object  properties 

User  Story  /  Context  of  Use: 

•  As  plan  execution,  war  gaming  or  other  evaluation  it  becomes  necessary  to  evaluate 
the  performance  of  particular  strategic  elements  on  the  associated  effects  that  element 
would  have.  To  be  able  to  capture  and  represent  this,  the  user  wishes  to  make  changes 
to  a  measure  or  indicator  associated  with  a  particular  Strategy  Object. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  An  operation  is  open  that  has  at  least  one  COA. 

•  A  Strategy  Object  exists. 

•  An  assessment  object  is  associated  with  a  Strategy  Object. 

Triggers:  User  wishes  to  modify  data  relating  to  an  assessment  object  associated  with  a 
Strategy  Object. 

Guarantees: 

•  All  guarantees  from  use  case  Create  Assessment  Object  hold. 

Main  Success  Scenario: 

•  User  elects  to  view/modify  an  assessment  object  to  a  particular  Strategy  Object. 

•  The  system  displays  the  assessment  object  editor. 

•  The  user  views/modifies  the  changes  and  confirms  completion  of  the  operation. 

•  The  system  persists  the  changes. 

Requirements: 

8. COA  Sketch  shall  provide  users  a  way  to  create/modify  data  associated  with  a  COA  or  Plan. 


Use  Case  3.18:  Delete  Assessment  Object 

User  Story  /  Context  of  Use: 
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•  After  an  assessment  object  has  been  associated  with  a  Strategy  Object,  the  users 
might  deem  that  the  assessment  is  unable  to  be  ascertained,  or  is  duplicated  in  another 
assessment  object,  or  completely  unnecessary. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Strategy  Planner 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  A  operation  is  open  that  has  at  least  one  COA. 

•  A  Strategy  Object  exists. 

•  An  assessment  object  is  associated  with  a  Strategy  Object. 

Triggers:  And  assessment  object  has  been  determined  to  be  unneeded  and  thus  the  user 
wishes  to  delete  the  assessment  object. 

Guarantees: 

•  All  guarantees  from  use  case  Create  Assessment  Object  hold. 

Main  Success  Scenario: 

•  User  elects  to  delete  an  assessment  object  from  a  particular  Strategy  Object. 

•  The  system  prompts  the  user  to  confirm  the  deletion. 

•  The  user  confirms  delete. 

•  The  system  persists  the  changes,  removing  the  assessment  object  from  the  Strategy 
Object. 

Alternative  1  (User  cancels  deletion): 

3.  The  user  elects  to  cancel  the  deletion  of  the  assessment  object. 

4.  The  system  reverts  to  its  previous  state,  with  the  assessment  object  still  associated 
with  the  Strategy  Object. 

Requirements: 

8. COA  Sketch  shall  provide  users  a  way  to  create/modify  data  associated  with  a  COA  or  Plan. 


Use  Case  3.19:  Add  COA  Sketch  Object  Timing 

User  Story  /  Context  of  Use: 

•  All  COA  Sketch  Objects  (Mission  Analysis  data.  Strategy  Planning  items. 

Assessment  items)  may  have  an  element  of  timing.  The  user  may  wish  to  add  these 
attributes  into  the  tool  so  that  they  may  use  the  visualizations  to  further  analyze  the 
Plan. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Strategy  Planner,  all  Planners 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  An  operation  is  open. 

•  A  Mission  Analysis,  Strategy  Object,  or  Assessment  Object  exists. 

Triggers: 
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•  A  planner  wishes  to  add  a  timing  element  to  an  existing  Mission  Analysis  object, 
Strategy  Object,  or  Assessment  Object. 

Guarantees: 

•  The  timing  information  will  be  viewable  in  both  textual  and  visual  forms 

•  The  user  will  be  able  to  edit  the  following  timing  information: 

1 .  Start  and  Stop  time 

2.  Start  after  and  Stop  by  time 

•  All  timing  information  will  be  relative  to  an  Alpha  Day. 

1 .  By  default,  the  timing  of  a  Mission  Analysis  object  will  be  r  elative  to  the  Operation’s 
Default  timing  (D-Day).  If  Use  Case  3.24  is  implemented,  then  the  tim  ing  will  b  e 
relative  to  the  designated  Alpha  Day. 

2.  By  default,  the  timing  of  Strategy  and  Mission  Analysis  objects  will  be  relative  to  the 
COA’s  default  timing  (D-Day),  which  m  ay  be  defined  or  be  using  the  Operation’s 
default  timing.  If  Use  Case  3.24  is  implemented,  then  the  timing  will  be  relative  to  the 
designated  Alpha  Day. 

3.  By  default,  the  Start  After  and  Stop  By  time  will  not  be  used. 

4.  By  default,  the  Start  date  depends  o  n  whether  or  not  a  hierarchy  is  in  place.  If  the 
CO  A  Sketch  Object  is  created  in  a  hierarchy  in  which  a  parent  or  grandparent  element 
has  timing,  the  start  date  will  be  the  same  as  the  most  im  mediate  parent  with  timing. 
Otherwise,  the  start  date  will  be  the  sam  e  as  D-Day,  or  if  Use  Case  3.23  is 
implemented,  then  the  timing  will  be  relative  to  the  designated  Alpha  Day. 

5.  By  default,  the  Stop  date  depends  o  n  whether  or  not  a  hierarchy  is  in  place.  If  the 
CO  A  Sketch  Object  is  created  in  a  hierarchy  in  which  a  parent  or  grandparent  element 
has  timing,  the  stop  date  will  be  the  same  as  the  most  im  mediate  parent  with  tim  ing. 
Otherwise,  the  stop  date  will  be  the  24  hours  after  the  Start  date. 

6.  Note:  If  the  child  objec  t  has  m  ultiple  immediate  parents  w  ith  timing  elements,  the 
child  will  inherit  the  start  date  that  occurs  last.  If  the  start  d  ate  that  occurs  last  is  also 
after  the  s  top  date  of  any  other  pa  rent,  th  en  the  system  will  warn  the  user  of  the 
situation  and  the  s  tart  date  will  b  e  the  sam  e  as  D-Day  and  the  Stop  date  will  be  24 
hours  after  the  start  date. 

Main  Success  Scenario: 

1.  The  user  selects  a  CO  A  Sketch  Object. 

2.  The  user  chooses  to  add  a  timing  element  to  the  selected  object. 

3.  The  system  determines  what  timing  to  use  by  default.  The  system  creates  a  timing 
element  referencing  the  D-Day  alpha  day  and  setting  up  the  default  information  on  it. 

4.  The  system  updates  displays  to  depict  the  new  timing  element. 

Alternative  1  (COA  Sketch  Object  has  multiple  parents  from  multiple  CO  As,  one  of 

which  is  not  using  the  default  operation  timing): 

1.  Perform  steps  1-2  of  the  Main  Success  Scenario 

2.  The  system  determines  that  the  COA  Sketch  Object  is  a  child  to  two  parents  who  both 
have  timing. 

3.  The  system  determines  that  the  parent’s  timing  are  referencing  different  Alpha  Days 

4.  The  system  requires  the  user  to  determine  which  Alpha  days  to  reference  (i.e.  the 
operation’s  defaults  or  the  timing  from  COA  X) 

5.  The  user  indicates  the  proper  Alpha  Days  to  use. 
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6.  The  system  uses  the  indieated  Alpha  days  to  reference  when  setting  up  the  default 
timing  information  by  converting  the  Alpha  Day  difference. 

a.  Determining  Alpha  day  conversion  between  different  CO  As: 

i.  D-Day  is  always  the  default  day.  Find  the  duration  offset  of  the  timing 
to  be  converted  from  D-Day.  (i.e.  if  date  is  M-i-10,  and  M  =  D-i-30, 
then  duration  offset  is  +40. 

ii.  Apply  this  duration  offset  as  the  new  offset  from  the  chosen  timing’s 
D-Day. 

7.  Return  to  step  4  of  Main  Success  Scenario. 
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Plan  Player  Use  Cases 

Use  Case  12.1:  User  chooses  Map  Sketch  View  player  features 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  find  it  helpful  to  be  able  to  “play”  through  the 
plan.  This  would  allow  them  to  view  the  plan  as  it  goes  through  the  Synchronization 
(Gantt  chart)  View  and  the  Map  Sketch  View  as  the  timing  of  different  objects  come 
into  and  out  of  focus. 

•  The  Team  Member  or  Reviewer  will  have  several  player  features  available  to  them 
for  better  enhancing  the  play  mode: 

•  View  the  Sketch  Objects  in  a  “Build”  or  “Compound”  mode,  which  will 
continuously  add,  based  on  the  chronological  sequence,  the  plan  element  icons  or 
shapes  to  the  map.  Once  a  plan  element  appears,  it  will  always  be  present. 

•  View  the  Sketch  Objects  in  a  “Parent  Compound”  mode,  which  is  similar  to 
“compound”  mode,  but  in  addition  will  hide  children  elements  once  all  siblings 
have  been  achieved.  If  the  parent  element  does  not  have  an  object  representation 
on  the  Map  Sketch  View,  the  children  will  disappear. 

•  View  the  Sketch  Objects  in  a  “Focus”  mode,  which  will  display  the  element  only 
when  the  player  focus  overlaps  the  planned/executed  time  range  of  the  object.  In 
other  words,  when  an  object  is  out  of  the  focus  time  range,  it  will  be  removed 
from  the  display. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Team  Member  or  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  Plan  Player  is  visible. 

•  Play  control  is  at  pause. 

Triggers:  The  Team  Member  or  Reviewer  wishes  to  modify  the  way  player  features 
function. 

Guarantees: 

•  The  player  features  selected  will  change  the  way  the  views  inte  ract  while  playing  the 
plan. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  view  the  Sketch  in  “focus”  mode. 

2.  The  system  updates  the  Map  Sketch  View  if  necessary  to  only  show  elements  in  the 
current  time  focus. 

3.  The  user  plays  the  plan,  (see  Use  Case  12.4) 

4.  The  system  updates  the  Map  Sketch  View  as  time  plays  on  so  that  only  elements  in 
the  current  time  focus  are  displayed 

Alternative  1:  Compound  Mode 

1 .  The  user  chooses  to  view  the  Sketch  in  “compound”  mode. 

2.  The  system  updates  the  Map  Sketch  View  if  necessary  to  show  elements  in  the  past 
and  current  time  focus. 

3.  The  user  plays  the  plan,  (see  Use  Case  12.4) 
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4.  The  system  updates  the  Map  Sketeh  View  as  time  plays  on  so  that  elements  in  the 
current  time  focus  are  displayed  in  addition  to  the  ones  in  the  past. 

Alternative  2:  Parent  Compound  Mode 

1 .  The  user  chooses  to  view  the  Sketch  in  “de-clutter”  mode. 

2.  The  system  updates  the  Map  Sketch  View  if  necessary  to  hide  children  elements  once 
all  siblings  have  been  achieved  in  the  past  and  current  time  focus. 

3.  The  user  plays  the  plan,  (see  Use  Case  12.4) 

4.  They  system  updates  the  Map  Sketch  View,  as  time  progresses,  hide  children 
elements  once  all  siblings  have  been  achieved  in  the  past  and  current  time  focus. 

Requirements: 

1 .  COA  Sketch  shall  display  plan  changes  over  time. 

2.  COA  Sketch  shall  display  geographical  changes  in  the  plan  over  time. 

3.  COA  Sketch  shall  display  sequence  changes  in  the  plan  over  time. 

4.  COA  Sketch  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 


Use  Case  12.2:  User  chooses  Play  Timing  -  Speed 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  find  it  helpful  to  be  able  to  “play”  through  the 
plan.  This  would  allow  them  to  view  the  plan  as  it  goes  through  the  Synchronization 
(Gantt  chart)  View  and  the  Map  Sketch  View  as  the  timing  of  different  objects  come 
into  and  out  of  focus. 

•  The  Team  Member  or  Reviewer  may  wish  to  change  the  speed  in  which  Player  Mode 
performs.  For  every  second  real  time,  the  player  will  advance  the  given  time.  This 
will  allow  Plan  Player  to  be  more  useable  to  different  audiences  in  the  time  frames 
available  to  them. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  COA  Sketch  Plan  Player  is  visible. 

•  Play  control  is  at  pause. 

Triggers:  The  Team  Member  or  Reviewer  wishes  to  modify  the  speed  of  the  presentation. 

Guarantees: 

•  The  temporal  features  selected  will  change  the  speed  of  the  playback. 

•  Player  will  have  a  default  speed  of  2  hrs.  Each  second  the  user  will  see  the  next  2 
hours  (single  hours  would  be  skipped)  of  the  plan. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  change  the  speed  of  the  playback. 

2.  The  system  displays  the  currently  set  speed. 

3.  The  user  modifies  the  playback  step  size  to  a  number  of  weeks,  days,  or  hours  and 
indicates  completion. 

4.  The  system  sets  the  new  playback  speed. 


B-48 


Alternative  1:  Cancel  Setting  Play  Speed 

1 .  The  user  chooses  to  change  the  speed  of  the  playback. 

2.  The  system  displays  the  currently  set  speed. 

3.  The  user  changes  the  speed 

4.  The  user  cancels  changing  the  speed. 

5.  The  system  remains  at  the  original  speed  in  step  2. 

Requirements: 

1 .  COA  Sketch  shall  display  plan  changes  over  time. 

2.  COA  Sketch  shall  display  geographical  changes  in  the  plan  over  time. 

3.  COA  Sketch  shall  display  sequence  changes  in  the  plan  over  time. 

5.  COA  Sketch  shall  provide  ability  to  display  changes  in  the  plan  over  time  at  multiple 
speeds. 

Use  Case  12.3:  User  chooses  Play  Timing  -  Focus  Time  Range 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  find  it  helpful  to  be  able  to  “play”  through  the 
plan.  This  would  allow  them  to  view  the  plan  as  it  goes  through  the  Synchronization 
(Gantt  chart)  View  and  the  Map  Sketch  View  as  the  timing  of  different  objects  come 
into  and  out  of  focus. 

•  The  Team  Member  or  Reviewer  may  wish  to  change  the  time  range  of  the  focus. 
Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  Plan  Player  is  visible. 

•  Play  control  is  at  pause. 

Triggers:  The  Team  Member  or  Reviewer  wishes  to  modify  the  focus  time  range  of  Player 
Mode. 

Guarantees: 

•  The  temporal  features  s  elected  will  change  the  focus  tim  e  range  of  the  views  durin  g 
playback. 

•  The  Player  will  have  a  default  focus  time  range  of  0  hours 

Main  Success  Scenario: 

1 .  The  user  chooses  to  change  the  time  range  of  the  current  time  focus. 

2.  The  system  displays  the  currently  set  time  range. 

3.  The  user  modifies  the  time  range  size  to  a  number  of  days  or  default. 

4.  The  system  sets  the  time  range. 

Alternative  1:  Cancel  Setting  Time  Range 

1 .  The  user  chooses  to  change  the  time  range  of  the  current  time  focus. 

2.  The  system  displays  the  currently  set  time  range. 

3.  The  user  changes  the  focus  time  range 

4.  The  user  cancels  changing  the  time  range. 

5.  The  system  remains  at  the  original  time  range  in  step  2. 

Requirements: 

1 .  COA  Sketch  shall  display  plan  changes  over  time. 
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2.  COA  Sketch  shall  display  geographical  changes  in  the  plan  over  time. 

3.  COA  Sketch  shall  display  sequence  changes  in  the  plan  over  time. 

6.  COA  Sketch  shall  be  able  to  adjust  the  time  range  displayed  geographically  and 
sequentially  over  time. 

Use  Case  12.4:  User  Plays  Plan 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  find  it  helpful  to  be  able  to  “play”  through  the 
plan.  This  would  allow  them  to  view  the  plan  as  it  goes  through  the  Synchronization 
(Gantt  chart)  View  and  the  Map  Sketch  View  as  the  timing  of  different  objects  come 
into  and  out  of  focus. 

•  The  focus  time  range  is  represented  on  the  Synchronization  View  and  is  especially 
important  when  viewing  the  plan  within  a  small  time  frame.  While  the  plan  is 
playing,  it  is  the  indicator  that  shows  the  user  which  time  period  of  the  plan  is 
currently  displayed. 

•  The  user  may  also  wish  to  pause  the  playback.  This  would  allow  the  users  the 
opportunity  to  discuss  what  is  going  on  in  the  plan  at  the  paused  time. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  Plan  Player  is  visible. 

•  Play  control  is  at  pause. 

Triggers:  The  Team  Member  or  Reviewer  wishes  to  play  the  plan  or  COA. 

Guarantees: 

•  COA  Sketch  will  begin  playing  the  plan  based  on  the  timing  the  user  had  selected. 

•  Pausing  the  playback  o  f  the  plan  will  allow  the  user  to  e  asily  beg  in  playing  a  t  the 
point  of  pausing. 

•  The  plan  will  not  be  editable  while  it  is  playing. 

•  The  plan  will  be  editable  when  it  is  paused. 

•  The  user  will  not  have  access  to  hiding/s  bowing  objects  in  different  views  of  COA 
Sketch  while  a  plan  is  playing. 

•  The  user  will  hav  e  ace  ess  to  hid  ing/showing  objects  in  d  ifferent  vie  ws  of  COA 
Sketch  while  a  plan  is  paused. 

Main  Success  Scenario: 

1 .  The  user  selects  to  play  the  plan. 

2.  The  system  plays  the  plan  by: 

i.  Displaying  the  current  focus  time  range  on  the  Player; 

ii.  Starting  play  at  the  current  focus  time; 

iii.  Moving  forward  at  the  set  speed; 

iv.  Updating  the  Map  Sketch  View  as  indicated  in  the  presentation  mode;  (see  Use 
Case  12.1) 

V.  Updating  the  focus  time  indication  on  the  Synchronization  View. 

3.  The  system  does  not  allow  the  plan  to  be  edited  while  playing  and  stops  the  play 
automatically  at  the  end  of  the  plan. 
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Alternative  1:  Pause  Play  during  Playback 

1 .  The  user  selects  to  play  the  plan  in  Player  Mode. 

2.  The  system  plays  the  plan  as  above. 

3.  The  user  selects  to  pause  the  plan. 

4.  The  system  halts  playing  the  plan  and  leaves  the  current  focus  time  range  at  the  point 
where  the  pause  occurred. 

5.  The  system  allows  the  plan  to  be  edited 

Requirements: 

1 .  COA  Sketch  shall  display  plan  changes  over  time. 

2.  COA  Sketch  shall  display  geographical  changes  in  the  plan  over  time. 

3.  COA  Sketch  shall  display  sequence  changes  in  the  plan  over  time. 

7.  COA  Sketch  shall  provide  a  way  to  display  the  focus  time  while  displaying  plan 
changes  over  time. 

8.  COA  Sketch  shall  be  able  to  pause  displaying  plan  changes  over  time. 

9.  COA  Sketch  shall  allow  the  user  to  edit  the  plan  while  displaying  plan  changes  over 
time 

10.  COA  Sketch  shall  allow  the  user  to  change  display  of  the  plan  while  displaying  plan 
changes  over  time. 

Use  Case  12.5:  User  Advances  and  Reviews  the  Plan 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  find  it  helpful  to  be  able  to  “play”  through  the 
plan.  This  would  allow  them  to  view  the  plan  as  it  goes  through  the  Synchronization 
(Gantt  chart)  View  and  the  Map  Sketch  View  as  the  timing  of  different  objects  come 
into  and  out  of  focus. 

•  The  Team  Member  or  Reviewer  may  find  it  helpful  to  move  forwards  and  backwards 
to  more  pertinent  pieces  and  parts  of  the  plan.  This  would  allow  them  a  more  focused 
discussion  of  the  plan  over  time. 

•  The  Team  Member  of  Review  may  find  it  helpful  to  move  forwards  or  backwards  to  a 
particular  date  by  selecting  a  phase,  D+n,  or  a  hard  date. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  Plan  Player  is  visible. 

•  The  plan  is  currently  playing. 

Triggers:  The  Team  Member  or  Reviewer  wishes  to  advance  or  review  the  play  through  of 
the  plan  or  COA. 

Guarantees: 

•  COA  Sketch  will  begin  playing  the  plan  based  on  the  timing  the  user  had  selected. 

•  Reviewing  the  plan  w  ill  allow  th  e  user  to  step  back  through  already  played 
information  and  replay  it  quickly. 

•  Advancing  the  plan  will  allow  the  user  to  step  ahead  to  skip  past  parts  of  the  plan  and 
begin  playing  the  plan  at  a  later  time. 

Main  Success  Scenario: 
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1 .  The  user  seleets  to  advanee  or  review  the  plan. 

2.  The  system  updates  the  Map  Sketeh  View  and  the  Synchronization  View  to  the 
desired  time  in  focus. 

3.  The  user  quits  stepping  back  or  forward  in  the  plan. 

4.  The  system  continues  playing  the  plan  from  the  desired  time  in  focus. 

Alternative  1:  Advance  /  Review  Paused  Plan 

1.  The  user  pauses  the  plan  from  playing,  (see  Use  Case  12.4  Alternatives) 

2.  The  system  pauses  playing  the  plan. 

3.  The  user  selects  to  advance  or  review  the  plan. 

4.  The  system  updates  the  Map  Sketch  View  and  the  Synchronization  View  to  the 
desired  time  in  focus. 

5.  The  user  quits  stepping  back  or  forward  in  the  plan. 

6.  The  system  remains  paused  at  the  desired  time  in  focus. 

Alternative  2:  Move  quickly  to  the  beginning  or  end  of  a  plan 

1 .  The  user  selects  to  move  to  the  beginning  or  end  of  the  plan. 

2.  The  system  updates  the  Map  Sketch  View  and  the  Synchronization  View  to  the 
desired  time  in  focus. 

Alternative  3:  Advance  /  Review  by  Selecting  Date 

1.  The  user  pauses  the  plan  from  playing,  (see  Use  Case  12.4  Alternatives) 

2.  The  system  pauses  playing  the  plan. 

3.  The  user  selects  to  advance  or  review  the  plan  to  a  specific  date  by  selecting  the 
phase;  D+  a  number;  or  a  day,  month,  and  year. 

4.  The  system  updates  the  Map  Sketch  View  and  the  Synchronization  View  to  the 
desired  time  in  focus. 

5.  The  system  remains  paused  at  the  desired  time  in  focus. 

Requirements: 

1 .  COA  Sketch  shall  display  plan  changes  over  time. 

2.  COA  Sketch  shall  display  geographical  changes  in  the  plan  over  time. 

3.  COA  Sketch  shall  display  sequence  changes  in  the  plan  over  time. 

1 1 .  COA  Sketch  shall  allow  the  user  to  focus  the  timing  in  which  the  plan  is  being 
displayed  overtime. 

Use  Case  12.6:  User  Adds  a  Comment 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  find  it  helpful  to  be  able  to  “play”  through  the 
plan.  This  would  allow  them  to  view  the  plan  as  it  goes  through  the  Synchronization 
(Gantt  chart)  View  and  the  Map  Sketch  View  as  the  timing  of  different  objects  come 
into  and  out  of  focus. 

•  During  play,  the  Team  Member  or  Reviewer  may  wish  to  make  a  comment  at  a 
specific  time  during  the  plan.  These  comments  could  work  as  a  reminder  to  the  Team 
Member  to  modify  something  about  the  plan  or  the  view  of  the  plan.  This  will  allow 
the  Team  Member  or  Reviewer  to  add  input  to  the  plan  without  having  to  exit  out  of 
play  mode  to  immediately  make  the  modifications. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 
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Supporting  Actors:  CO  A  Sketch 
Preconditions: 

•  Plan  Player  View  is  open 

•  Play  control  is  paused. 

Triggers:  The  Team  Member  or  Reviewer  wishes  to  add  a  comment  at  a  specific  time  in  the 
plan. 

Guarantees: 

•  The  comment  added  will  be  associated  to  the  time  in  which  the  time  focus  is  currently  set. 

•  If  the  focus  time  is  set  to  a  range,  the  note  will  be  added  at  the  beginning  of  the  time  range. 

•  More  than  one  comment  can  be  associated  to  the  same  time. 

Main  Success  Scenario: 

1 .  The  user  indicates  they  wish  to  add  a  note. 

2.  The  system  prompts  user  for  the  text  of  the  comment. 

3.  The  user  enters  comments  and  indicates  they  are  finished. 

4.  The  system  associates  the  comment  with  the  current  time  in  focus  and  indicates  to  the 
user  that  a  note  is  present. 

Alternative  1:  Cancel  Adding  Comment 

1 .  The  user  indicates  they  wish  to  add  a  note. 

2.  The  system  prompts  user  for  the  text  of  the  comment. 

3.  The  user  cancels  the  comment 

4.  The  system  returns  to  its  previous  state  with  no  new  note. 

Alternative  2:  Adding  Comment  without  pausing 

1 .  The  user  indicates  they  wish  to  add  a  note. 

2.  The  system  prompts  user  for  the  text  of  the  comment  while  continuing  to  play  the 
plan. 

3.  The  user  enters  the  comment  and  indicates  they  are  finished. 

4.  The  system  associates  the  comment  with  the  time  in  focus  at  initiation  of  the  note  and 
indicates  to  the  user  that  a  note  is  present. 

Requirements: 

1 .  COA  Sketch  shall  display  plan  changes  over  time. 

2.  COA  Sketch  shall  display  geographical  changes  in  the  plan  over  time. 

3.  COA  Sketch  shall  display  sequence  changes  in  the  plan  over  time. 

12.  COA  Sketch  shall  allow  a  user  to  add  comments  to  the  plan. 

13.  COA  Sketch  shall  allow  the  user  to  associate  comments  to  timing  within  the  plan. 


Use  Case  12.7:  User  Removes  a  Comment 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  find  it  helpful  to  be  able  to  “play”  through  the 
plan.  This  would  allow  them  to  view  the  plan  as  it  goes  through  the  Synchronization 
(Gantt  chart)  View  and  the  Map  Sketch  View  as  the  timing  of  different  objects  come 
into  and  out  of  focus. 

•  It  also  allows  the  Team  Member  or  Reviewer  the  opportunity  to  provide  input  or 
insight  by  adding  comments  to  the  plan  over  time. 

•  These  comments  can  then  be  looked  back  on  later  in  order  to  be  used  as  a  reminder  or 
as  something  requiring  further  clarification  and  modifications  to  the  plan. 
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•  Once  a  comment  is  no  longer  useful  to  the  team,  it  may  be  removed  from  the  system. 
Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  Plan  Player  View  is  open. 

•  There  is  at  least  one  comment. 

Triggers:  The  Team  Member  or  Reviewer  would  like  to  remove  an  existing  comment. 

Guarantees: 

•  The  comment  will  no  longer  be  available  to  the  Team  Member  or  Reviewer. 

Main  Success  Scenario: 

1 .  The  user  indicates  they  wish  to  delete  a  comment. 

2.  The  system  asks  for  confirmation  in  deletion. 

3.  The  user  confirms  delete. 

4.  The  system  removes  the  comment. 

Alternative  1:  Cancel  Deletion 

1 .  The  user  indicates  they  wish  to  delete  a  specific  comment. 

2.  The  system  asks  for  confirmation  in  deletion. 

3.  The  user  cancels  the  delete  action. 

4.  The  system  does  not  remove  the  comment  and  returns  to  previous  state. 

Requirements: 

1 .  COA  Sketch  shall  display  plan  changes  over  time. 

2.  COA  Sketch  shall  display  geographical  changes  in  the  plan  over  time. 

3.  COA  Sketch  shall  display  sequence  changes  in  the  plan  over  time. 

12.  COA  Sketch  shall  allow  a  user  to  add  comments  to  the  plan. 

13.  COA  Sketch  shall  allow  the  user  to  associate  comments  to  timing  within  the  plan. 


Use  Case  12.8:  User  Views/Edits  a  Comment 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  find  it  helpful  to  be  able  to  “play”  through  the 
plan.  This  would  allow  them  to  view  the  plan  as  it  goes  through  the  Synchronization 
(Gantt  chart)  View  and  the  Map  Sketch  View  as  the  timing  of  different  objects  come 
into  and  out  of  focus. 

•  It  also  allows  the  Team  Member  or  Reviewer  the  opportunity  to  provide  input  or 
insight  by  adding  comments  to  the  plan  over  time.  These  comments  can  then  be 
looked  back  on  later  in  order  to  be  used  at  a  reminder  or  as  something  requiring 
further  clarification  and  modifications  to  the  plan. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  Plan  Player  View  is  open. 

•  There  is  at  least  one  comment. 
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Triggers:  The  Team  Member  or  Reviewer  would  like  to  view  or  edit  an  existing  comment. 

Guarantees: 

•  The  comment  will  be  made  available  for  viewing  or  editing. 

•  All  modifications  to  the  comment  will  be  reflected  in  the  tool. 

Main  Success  Scenario: 

1 .  The  user  indicates  they  wish  to  view  a  comment. 

2.  The  system  displays  the  comment. 

3.  The  user  closes  the  comment  view. 

4.  The  system  returns  to  previous  state. 

Alternative  1:  View  Multiple  Comments 

1 .  The  user  indicates  they  wish  to  view  a  comment. 

2.  The  system  displays  the  comment. 

3.  The  user  indicates  they  wish  to  view  another  comment. 

4.  The  system  displays  the  additional  comment. 

5.  The  user  closes  one  comment  view. 

6.  The  system  removes  the  appropriate  comment  view. 

7.  The  user  closes  the  remaining  comment. 

8.  The  system  returns  to  previous  state,  with  no  comment  views  shown. 

Alternative  2:  Edit  Comment 

1 .  The  user  indicates  they  wish  to  view  a  comment. 

2.  The  system  displays  the  comment. 

3.  The  user  edits  the  comment  and  indicates  completion. 

4.  The  system  saves  the  edited  comment  and  returns  to  previous  state. 

Alternative  3:  Cancel  Editing  Comment 

1 .  The  user  indicates  they  wish  to  view  a  comment. 

2.  The  system  displays  the  comment. 

3.  The  user  edits  the  comment. 

4.  The  user  wishes  to  cancel  saving  the  edited  comment. 

5.  The  system  does  not  save  the  edited  comment  and  returns  to  previous  state. 

Requirements: 

1 .  COA  Sketch  shall  display  plan  changes  over  time. 

2.  COA  Sketch  shall  display  geographical  changes  in  the  plan  over  time. 

3.  COA  Sketch  shall  display  sequence  changes  in  the  plan  over  time. 

12.  COA  Sketch  shall  allow  a  user  to  add  comments  to  the  plan. 

13.  COA  Sketch  shall  allow  the  user  to  associate  comments  to  timing  within  the  plan. 


Use  Case  12.9:  User  Sets  Start  or  Stop  Date 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  find  it  helpful  to  be  able  to  “play”  through  the 
plan.  This  would  allow  them  to  view  the  plan  as  it  goes  through  the  Synchronization 
(Gantt  chart)  View  and  the  Map  Sketch  View  as  the  timing  of  different  objects  come 
into  and  out  of  focus. 

•  The  Team  Member  or  Reviewer  may  wish  to  change  the  start  date  or  stop  date  of  the 
player.  This  will  allow  them  to  focus  on  a  subset  of  the  plan. 
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•  The  Team  Member  of  Reviewer  may  set  the  start  and  stop  dates  by  selecting  phases, 
D+n,  or  hard  dates. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  Plan  Player  is  visible. 

•  Play  control  is  at  pause. 

•  The  Player  will  have  the  default  of  playing  the  entire  plan 

Triggers:  The  Team  Member  or  Reviewer  wishes  to  modify  the  start  or  stop  time  of  the 
playback 

Guarantees: 

•  The  Map  Sketch  View  in  either  C  ompound  or  Parent  Co  mpound  m  ode  will  on  ly 
contain  elements  within  the  start  and  stop  date,  not  the  entire  plan. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  set  the  start  or  stop  dates. 

2.  The  system  displays  the  currently  set  start  and  stop  dates. 

3.  The  user  modifies  the  dates  by  selecting  phases. 

4.  The  system  sets  the  start  and  stop  dates  and  resets  the  player. 

Alternative  1:  Sets  Dates  by  D+n 

1 .  The  user  chooses  to  set  the  start  or  stop  dates. 

2.  The  system  displays  the  currently  set  start  and  stop  dates. 

3.  The  user  modifies  the  dates  by  selecting  D  +  some  number. 

4.  The  system  sets  the  start  and  stop  dates  and  resets  the  player. 

Alternative  2:  Sets  Dates  by  Hard  Date 

1 .  The  user  chooses  to  set  the  start  or  stop  dates. 

2.  The  system  displays  the  currently  set  start  and  stop  dates. 

3.  The  user  modifies  the  dates  by  selecting  a  month,  day,  and  year. 

4.  The  system  sets  the  start  and  stop  dates  and  resets  the  player. 

Alternative  3:  Resets  to  View  Entire  Plan 

1 .  The  user  chooses  to  set  the  start  or  stop  dates. 

2.  The  system  displays  the  currently  set  start  and  stop  dates. 

3.  The  user  modifies  the  dates  by  selecting  to  view  the  entire  plan. 

4.  The  system  sets  the  start  and  stop  dates  and  resets  the  player. 

Alternative  4:  Cancel  Set  Dates 

1 .  The  user  chooses  to  set  the  start  or  stop  dates. 

2.  The  system  displays  the  currently  set  start  and  stop  dates. 

3.  The  user  modifies  the  dates. 

4.  The  user  cancels  changing  the  dates 

5.  The  system  keeps  the  original  start  and  stop  dates. 
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Requirements: 

1 .  COA  Sketch  shall  display  plan  changes  over  time. 

2.  COA  Sketch  shall  display  geographical  changes  in  the  plan  over  time. 

3.  COA  Sketch  shall  display  sequence  changes  in  the  plan  over  time. 

4.  COA  Sketch  shall  allow  the  user  to  focus  the  timing  in  which  the  plan  is  being 
displayed  overtime 
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Situational  Reference  Point  Use  Cases 

Use  Case  6.1:  Add  Situational  Reference  Point 

User  Story  /  Context  of  Use: 

The  user  wants  to  add  a  Situational  Referenee  Point  so  that  current  view  can  be  restored  at  a 
later  time. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

A  plan  is  open  in  COA  Sketch. 

Triggers:  User  wants  to  add  situation  reference  point 

Guarantees: 

Systems  saves  information  about  the  current  system  settings  and  views  such  as  current  zoom 
level,  map  type,  physical  location,  synchronization  view  settings  and  view,  hidden  and 
displayed  objects,  plan  player  and  window  layout  are  stored  so  that  the  user  can  return  to  the 
same  location  at  a  later  time. 

Main  Success  Scenario: 

1 .  The  user  selects  the  “Add  Situational  Reference  Point”  option  from  COA  Sketch. 

2.  The  system  prompts  user  for  the  name  of  the  Situational  Reference  Point. 

3.  The  user  provides  a  name  for  the  Situational  Reference  Point. 

4.  The  user  selects  the  location  to  the  store  the  Situational  Reference  Point 

5.  The  system  stores  the  current  zoom  level,  map  type,  physical  location,  synchronization 
view  settings  and  view,  and  window  layout  and  view  as  a  new  Situational  Reference 
Point. 

Alternative  1:  User  leaves  name  blank 

1 .  The  system  prompts  user  for  the  name  of  the  Situational  Reference  Point. 

2.  The  user  leaves  the  name  blank. 

3.  The  system  alerts  the  user  with  a  note  that  a  Situational  Reference  Point  must  have  a 
name. 

4.  User  confirms  the  alert. 

5.  System  is  back  at  step  2,  prompting  the  user  for  a  Situational  Reference  Point  name. 
Alternative  2:  User  enters  name  already  in  existence 

1 .  The  system  prompts  user  for  the  name  of  the  Situational  Reference  Point. 

2.  The  user  enters  a  name  that  was  used  previously. 

3.  The  system  alerts  the  user  with  a  note  that  a  Situational  Reference  Point  name  already 
exists. 

4.  User  confirms  the  alert. 

5.  System  is  back  at  step  2,  prompting  the  user  for  a  Situational  Reference  Point  name. 
Alternative  3:  User  cancels  creation  of  SRP 

1 .  The  user  selects  the  “Add  Situational  Reference  Point”  option  from  COA  Sketch. 

2.  The  user  cancels  creation  of  Situational  Reference  Point 

Requirements: 

1 .  COA  Sketch  shall  save  system  displays  of  a  COA  Plan  to  aid  the  user  in  reimursing 
himself  back  into  the  plan. 
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2.  COA  Sketch  shall  save  system  displays  of  a  COA  Plan  to  brief  or  show  team  members 
context  of  a  COA  Plan. 


Use  Case  6.2:  Remove  Situational  Reference  Point 

User  Story  /  Context  of  Use: 

The  user  wants  to  remove  a  Situational  Reference  Point  that  is  no  longer  useful. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

A  plan  is  open  in  COA  Sketch. 

A  Situational  Reference  Point  exists. 

Triggers:  User  wants  to  remove  Situational  Reference  Point 

Guarantees: 

The  Situational  Reference  Point  is  removed. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  delete  a  Situational  Reference  Point. 

2.  The  system  displays  the  Situational  Reference  Point  list. 

3.  The  user  selects  a  Situational  Reference  Point  for  deletion. 

4.  The  user  selects  to  delete. 

5.  The  system  removes  the  Situational  Reference  Point. 

Alternative  1:  Remove  SRP  using  an  SRP  Organizer 

1 .  The  user  chooses  to  delete  a  Situational  Reference  Point. 

2.  The  user  selects  the  Situational  Reference  Points  Organizer 

3.  The  system  displays  the  Situational  Reference  Point  list. 

5.  The  user  selects  a  Situational  Reference  Point  for  deletion. 

6.  The  user  selects  to  delete. 

7.  The  system  removes  the  Situational  Reference  Point. 

Alternative  2:  User  cancels  delete 

1 .  The  user  chooses  to  delete  a  Situational  Reference  Point. 

2.  The  user  selects  the  Situational  Reference  Points  Organizer 

3.  The  system  displays  the  full  Situational  Reference  Point  list. 

5.  The  user  cancels. 

Requirements: 

1 .  COA  Sketch  shall  save  system  displays  of  a  COA  Plan  to  aid  the  user  in  reimursing 
himself  back  into  the  plan. 

2.  COA  Sketch  shall  save  system  displays  of  a  COA  Plan  to  brief  or  show  team  members 
context  of  a  COA  Plan. 


Use  Case  6.3:  Go  to  Situational  Reference  Point 

User  Story  /  Context  of  Use: 

The  user  wants  to  visit  a  Situational  Reference  Point  that  was  created  earlier. 
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Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

A  plan  is  open  in  COA  Sketch. 

A  Situational  Reference  Point  exists. 

Triggers:  The  user  wants  to  visit  Situational  Reference  Point  created  previously. 

Guarantees: 

The  system  restores  the  current  zoom  level,  map  type,  physical  location,  synchronization 
view  settings  and  view,  and  window  layout 

Main  Success  Scenario: 

1 .  The  user  selects  a  Situational  Reference  Point  from  COA  Sketch. 

2.  The  system  informs  the  user  that  all  previously  open  windows  will  now  close. 

3  The  user  confirms. 

2.  The  system  closes  all  currently  open  windows 

2.  The  system  restores  the  current  zoom  level,  map  type,  physical  location,  synchronization 
view  settings  and  view,  and  window  layout. 

Alternative  1:  User  cancels  opening  an  SRP 

1 .  The  user  selects  a  Situational  Reference  Point  from  COA  Sketch. 

2.  The  system  informs  the  user  that  all  previously  open  windows  will  now  close. 

3.  The  user  cancels. 

4.  The  system  stays  in  previous  state. 

Requirements: 

1 .  COA  Sketch  shall  save  system  displays  of  a  COA  Plan  to  aid  the  user  in  reimursing 
himself  back  into  the  plan. 

2.  COA  Sketch  shall  save  system  displays  of  a  COA  Plan  to  brief  or  show  team  members 
context  of  a  COA  Plan. 


Use  Case  6.4:  Organize  Situational  Reference  Points 

User  Story  /  Context  of  Use: 

The  user  wants  to  organize  the  Situational  Reference  Points  already  created. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

A  plan  is  open  in  COA  Sketch. 

Situational  Reference  Points  exist. 

Triggers:  The  user  wants  to  organize  situational  reference  points. 

Guarantees: 

An  “Organize  Situational  Reference  Point”  window  is  displayed  along  with  all  Situational 
Reference  Points  previously  created  by  user. 

Main  Success  Scenario: 
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1 .  The  user  chooses  Situational  Reference  Point  from  Organize  Situational  Reference  Points 
window  in  COA  Sketch. 

2.  The  user  selects  Situational  Reference  Point  and  indicates  where  they  want  it  to  be 
located. 

3.  The  system  displays  the  Situational  Reference  Point  in  the  new  location. 

Alternative  1:  User  renames  folder 

1 .  The  user  chooses  Situational  Reference  Point  from  Organize  Situational  Reference  Points 
window  in  COA  Sketch. 

2.  The  user  chooses  to  rename  the  Situational  Reference  Point. 

3.  The  system  prompts  for  a  new  name 

4.  The  user  updates  the  name  of  the  Situational  Reference  Point. 

5.  The  system  shows  the  new  name 

Alternative  2:  User  deletes  Situational  Reference  Point 

1 .  The  user  chooses  Situational  Reference  Point  from  Organize  Situational  Reference  Points 
window  in  COA  Sketch. 

2.  The  user  chooses  to  delete  the  Situational  Reference  Point 

3.  The  system  asks  user  to  confirm  deletion 

4.  The  user  confirms  deletion 

5.  The  system  removes  Situational  Reference  Point  from  list 

Alternative  3:  User  creates  new  folder 

1 .  The  user  chooses  the  “Create  Folder”  button  from  the  Organize  Situational  Reference 
Points  window  in  COA  Sketch. 

2.  The  system  displays  a  new  folder  in  the  Situational  Reference  Points  list  with  the  name 
‘New  Folder”  highlighted  and  editable. 

3.  The  user  changes  the  name  of  the  folder  to  desired  name. 

4.  System  displays  new  name  for  folder. 

Alternative  4:  User  deletes  Folder 

1 .  The  user  chooses  a  folder  from  Organize  Situational  Reference  Points  window  in  COA 
Sketch. 

2.  The  user  chooses  the  folder  to  delete 

3.  The  system  asks  user  to  confirm  deletion 

4.  The  user  confirms  deletion 

5.  The  system  removes  the  folder 

Requirements: 

1 .  COA  Sketch  shall  save  system  displays  of  a  COA  Plan  to  aid  the  user  in  reimursing 
himself  back  into  the  plan. 

2.  COA  Sketch  shall  save  system  displays  of  a  COA  Plan  to  brief  or  show  team  members 
context  of  a  COA  Plan. 
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Sketch  View  Use  Cases 

Italicized  are  future  spiral  requirements. 


Use  Case  4.1:  Team  Member  Sets  Default  Visual  Appearance  by 
Category  or  Strategy  Plan  Level 

User  Story  /  Context  of  Use: 

•  A  Team  member  may  wish  to  set  a  default  color,  transparency,  line  style,  line  color,  line 
width,  or  line  transparency  for  a  category  of  COA  Sketch  objects.  As  new  map  objects  are 
created  for  these  COA  Sketch  objects,  they  will  have  the  set  defined  properties. 

•  A  Team  member  may  wish  to  set  a  default  color,  transparency,  line  style,  line  color,  line 
width,  or  line  transparency  for  a  Strategy  Plan  Level  of  COA  Sketch  objects.  As  new  map 
objects  are  created  for  these  COA  Sketch  objects,  they  will  have  the  set  defined  properties. 

•  A  Team  member  may  wish  to  set  a  default  color,  transparency,  shape,  line  style,  line  color, 
line  width,  or  line  transparency  for  a  user  defined  tas  of  COA  Sketch  objects.  As  new  map 
objects  are  created  for  these  COA  Sketch  objects,  they  will  have  the  set  defined  properties.  (In 
Future  Spiral) 

•  Depending  upon  the  zoom  level  displayed  in  the  geographic  region,  some  Strategy  Plan  Level 
information  may  only  be  useful  when  displayed  at  specific  zoom  levels.  Because  of  this,  the 
team  members  should  be  able  to  set  what  these  levels  are  for  a  strategy  element  type.  This  will 
aid  in  a  proper  filter  of  the  map  to  help  with  situational  awareness  and  reduce  cognitive  load. 

•  Depending  upon  the  zoom  level  displayed  in  the  geographic  region,  some  categories  may  only 
be  useful  when  displayed  at  specific  zoom  levels.  Because  of  this,  the  team  members  should 
be  able  to  set  what  thes  e  levels  are.  This  will  aid  in  a  proper  filter  of  the  m  ap  to  help  with 
situational  awareness  and  reduce  cognitive  load. 

•  Depending  upon  the  zoom  level  displayed  in  the  geographic  region,  some  user-defined  objects 
may  only  be  useful  when  displayed  at  specific  zoom  levels.  Because  of  this,  the  team  members 
should  be  able  to  set  these  levels.  The  ability  to  do  this  at  the  tag-level  will  allow  the  user  to 
reduce  repetitive  tasks.  This  will  also  aid  in  a  proper  filter  of  the  map  to  help  with  situational 
awareness  and  reduce  cognitive  load.  (In  Future  Spiral) 

•  A  Team  member  may  wish  to  apply  a  user  defined  preference  for  map  properties  to  only  new 
map  objects  or  apply  it  to  existing  map  objects. 

Scope:  User  to  COA  Sketch  Interaction,  Changes  made  apply  to  all  projects. 

Level:  User  Goal 

Primary  Actor:  Team  Member 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

•  The  Sketch  View  is  open. 

Triggers: 

•  The  Team  Member  wants  to  change  their  preferences  used  to  set  the  map  properties  of  a 
category  or  strategy  plan  level. 

Guarantees: 

•  The  strategy  plan  levels  available  for  setting  default  map  properties  are:  National 
Objectives 
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o  National  Task 
o  National  Activity 
o  Strategic  Objectives 
o  Strategie  Tasks 
o  Strategie  Aetivity 
o  Operational  Objectives 
o  Operational  Tasks 
o  Operational  Aetivity 
o  Taetieal  Objective 
o  Taetieal  Tasks 
o  Taetieal  Activity 

•  The  map  properties  available  to  set  for  the  preferenee  are: 
o  fill  color 

o  fill  transparency 
o  border  style 
o  border  color 
o  border  width 
o  border  transpareney 

o  minimum  /  maximum  zoom  levels.  If  zoomed  in  any  closer  than  the  maximum 
level,  the  objeet  will  be  hidden.  If  “zoomed  out”  any  further  than  the  minimum 
level,  the  object  will  be  hidden.  Otherwise,  the  object  is  visible.  If  neither  is  set, 
the  objeet  is  always  visible. 

o  (shape  is  intentionally  left  off  the  list  because  a  shape  is  selected  when  placing  a 
map  object  on  the  sketeh  view) 

•  The  map  objects  will  show  up  on  the  map  only  at  the  speeified  zoom  levels. 

•  The  user  defined  settings  may  be  applied  to  already  existing  map  objects  or  to  only 
newly  ereated  map  objects. 

Main  Success  Scenario: 

1 .  The  user  indicates  the  desire  to  set  the  map  property  preferenees 

2.  The  system  displays  a  list  of  eategories,  strategy  plan  levels,  and  user  defined  tags 
that  can  be  set 

3.  The  user  selects  the  type  of  element  to  update. 

4.  The  user  speeifies  if  ehanges  should  be  made  to  only  new  objects,  only  existing 
objects,  or  new  and  existing  objeets. 

5.  The  system  displays  the  eurrent  settings 

6.  The  user  updates  map  properties  as  desired  and  indicates  they  are  done 

7.  The  system  updates  the  display  of  relevant  map  elements  with  the  new  visual 
properties. 

Alternative  1:  Cancel  setting  preferences 

5.  The  user  decides  to  eancel  setting  the  map  properties 

6.  The  system  remains  at  the  previous  settings 

Requirements: 

1 .  COA  Sketeh  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 
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Use  Case  4.2:  Team  Member  Creates  New  Map  Objects 

User  Story  /  Context  of  Use: 

•  The  Team  Member  wants  to  place  a  Map  Object  (shape,  icon,  or  target  type)  on  the 
map  to  represent  a  new  CO  A  Sketch  object.  This  will  allow  the  Team  Member  or 
Reviewer  to  have  both  a  temporal  and  geographical  understanding  of  how  the  object 
affects  the  Strategic  Plan. 

•  The  Team  Member  may  have  created  a  CO  A  Sketch  object  utilizing  the 
synchronization  view  and  now  wishes  to  create  an  associated  Map  Object  (a  shape, 
icon,  or  target  type).  This  will  allow  the  Team  Member  or  Reviewer  to  have  both  a 
temporal  and  geographical  understanding  of  how  the  object  affects  the  Strategic  Plan. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Team  Member 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  COA  Sketch  is  open. 

•  A  project  is  open. 

•  The  Sketch  View  is  open. 

Triggers:  Team  Member  needs  to  create  a  new  Map  Object  to  represent  some  information. 

Guarantees: 

•  No  Map  Objects  can  exist  without  being  associated  with  one  and  only  one  COA  Sketch  Object 

•  A  COA  Sketch  object  can  have  more  than  one  map  object  associated  with  it. 

•  The  new  Map  Object  w  ill  have  timing  information  associated  with  it.  By  default,  it  will  have 
the  same  timing  as  the  COA  Sketch  object  associated  with  it. 

•  The  new  Map  Object  will  have  geographical  context  associated  with  it. 

•  The  Map  Object  will  be  added  as  an  icon,  shape,  or  target  type  to  the  Sketch  View. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  create  a  new  shape  or  icon. 

2.  The  system  displays  the  available  shapes  or  icons. 

3.  The  user  selects  a  shape  or  icon  and  places  it  on  the  m  ap  at  the  desired  location  and 
size. 

4.  The  user  selects  the  type  of  the  COA  Sketch  object  to  be  created 

5.  The  system  creates  the  COA  Sketch  obj  ect.  (See  creatin  g  new  COA  objects  in 
Plan  COA  Use  Cases  Spiral  One  and  creating  new  m  ission  analysis  objects  in 
Mission  Analysis  Use  Cases) 

6.  The  system  draws  the  shape  according  to  the  m  ap  property  preferences  for  its 
category  or  strategy  plan  level. 

7.  The  system  associates  the  shape  to  the  new  COA  Sketch  Object 

Alternative  1:  Associate  shape  with  existing  COA  Sketch  object 

1 .  The  user  chooses  to  create  a  new  shape  or  icon. 

2.  The  system  displays  the  available  shapes  or  icons. 

3.  The  user  selects  a  shape  or  icon  and  places  it  on  the  m  ap  at  the  desired  location  and 
size. 

4.  The  user  selects  existing  COA  Sketch  object  to  associate  with  the  shape 
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5.  The  system  draws  the  shape  aeeording  to  the  m  ap  property  preferenees  for  its 
category  or  strategy  plan  level. 

6.  The  system  associates  the  shap  e  to  the  existing  COA  Sketch  Obje  ct,  if  th  ere  is 
another  shape  associated  with  the  COA  Sketch  Object,  it  remains. 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 


Use  Case  4.3:  Team  Member  Associates  Map  Objects  to  different 
Timings  of  COA 

User  Story  /  Context  of  Use: 

•  The  Team  Member  may  also  use  two  or  more  shapes/icons  to  show  how  the  focus  of 
operations  may  shift  within  or  across  phases  of  the  COA. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

•  The  Sketch  View  is  open. 

Triggers: 

•  The  Team  member  wants  to  use  different  shapes/icons  to  represent  the  same  COA  Sketch 
Object  at  different  points  in  time. 

Guarantees: 

•  The  user  can  associate  different  map  objects  with  different  timing  to  one  COA  Sketch 
object. 

Main  Success  Scenario: 

1 .  The  user  selects  to  modify  the  timing  of  one  Map  Object. 

2.  The  system  displays  the  current  timing  of  the  Map  Object. 

3.  The  user  adjusts  the  timing  of  the  Map  Object 

4.  The  system  updates  to  reflect  the  new  timing 

Alternative  1:  User  moves  timing  outside  of  the  COA  Sketch  Object  Timing 

4.  The  system  alerts  the  user  the  timing  falls  outside  of  the  COA  Sketch  Object 

5.  The  user  selects  to  allow  the  COA  Sketch  Object  to  adjust  to  contain  map  object 
timing 

6.  The  system  adjusts  the  COA  Sketch  Object  timing. 

Alternative  2:  User  moves  timing  outside  of  the  COA  Sketch  Object  Timing  -cancel 
timing  change 

4.  The  system  alerts  the  user  the  timing  falls  outside  of  the  COA  Sketch  Object 

5.  The  user  selects  to  cancel  the  COA  Sketch  Object  timing  adjustment 

6.  The  system  returns  the  Map  Object  to  its  previous  state. 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 
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Current  techniques: 


COA  1  COUNTERLAND 

Early  Phqs 


Gain  air  superiority 
over  NV  and  over  CA 
2d  ech  forces  by  D+3 
Heaviest  effort  in  Ph  II 
is  to  culminating  CA 
offensive 

Use  economy  of  effort 
(primarily  TLAM  & 
CALCM)  to  disrupt  POL 
&  ammo  prod  &  dist 


r£  I 


Disrupt  POL  & 
Ammo  Prod'tn  & 
Distribution 


COA  1  COUNTERLAND 

Later  Phase  II 


Expand  air  superiority 
to  include  central  CA 

-  WMD  capable  AC  &  msis 
Isolate  &  attrit  forces  in 
Pacifica  Mineral  Fields 
Isolate  &  attrit  forces 
opposing  forced  entry 

-  Support  deception  ops  j 


Expand  air  superiority 
to  include  central  CA 


Prep  AOA  for 
forced  entry 


Isolate  &  attrit  two 
corps  in  PMF 


Implementation  ideas: 

1 .  Would  like  to  express  broad  efforts  through  Operational  objectives,  e.g.  showing  air 
superiority  status  through  changes  in  color  of  specified  areas. 

2.  Show  change  in  effects  over  time  (playthrough). 


Use  Case  4.4:  Team  Member  Selects  Map  Object  on  Sketch  View 

User  Story  /  Context  of  Use: 

•  In  order  to  create  a  more  successful  picture  of  the  battle  space  and  the  plan,  it  will  be 
important  that  team  members  have  the  ability  to  cut,  copy,  delete,  modify,  or  view  the 
properties  of  a  COA  Sketch  Object  or  Map  Object.  This  will  help  the  team  maintain 
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situational  awareness  and  will  lead  to  a  better  understanding  of  the  COA  being 
developed. 

Scope:  User  to  COA  Sketeh  Interaction 

Level:  User  Goal 

Primary  Actor:  Team  member 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  A  project  is  open  in  COA  Sketch  that  has  at  least  one  map  object  on  the  Sketch  View 
to  select. 

Triggers:  The  user  wishes  to  select  map  objects  to  cut,  copy,  delete,  modify  or  view  the 

properties  of  a  COA  Sketch  or  map  object. 

Guarantees: 

•  Only  map  objects  associated  with  a  single  COA  Sketch  Object  can  be  selected  at  one 
time.  Multiple  COA  Sketch  Objects  can  not  be  selected  at  once. 

Main  Success  Scenario:  (Only  one  Map  Object  associated  with  the  COA  Sketch  Object) 

1 .  The  user  selects  an  existing  object  on  the  map. 

2.  The  system  indicates  the  Map  Object(s)  and  its  COA  Sketch  object  in  all  other  open 
views  (if  it  is  visible  without  scrolling,  un-hiding,  etc.)  is  selected.  (See  selection  use 
cases  in  Overall  Use  Cases  Spiral  one) 

3.  The  user  chooses  to  edit  the  selected  objects. 

4.  The  system  enables  all  COA  Sketch  object-specific  and  map  properties  editing 
options. 

Alternative  1:  Multiple  Map  Objects  associated  with  one  COA  Sketch  Object 

5.  The  user  chooses  to  only  select  the  original  object. 

6.  The  system  removes  selection  from  the  other  map  objects  associated  with  the  COA 
Sketch  object. 

Alternative  2:  Multiple  Map  Objects  associated  with  one  COA  Sketch  Object 

5.  The  user  chooses  to  deselect  one  or  more  map  objects 

6.  The  system  removes  selection  from  the  deselected  map  objects. 

Requirements: 

2. COA  Sketch  shall  allow  the  user  to  edit  objects  on  a  map  view. 


Use  Case  4.5:  Team  Member  Modifies  Map  Specific  Object  Properties 

User  Story  /  Context  of  Use: 

•  In  order  to  create  a  more  successful  picture  of  the  battle  space  and  the  plan,  it  will  be 
important  that  team  members  have  the  ability  to  modify  map  information  in  existing 
map  objects.  This  will  help  the  team  maintain  situational  awareness  and  will  lead  to  a 
better  understanding  of  the  COA  being  developed. 

•  Due  to  the  ever  changing  nature  of  each  COA,  and  the  situation  dependent 
Operational  Environmental,  pieces  and  parts  of  information  are  important  to 
determining  Courses  of  Action  and  their  underlying  effects,  it  is  important  that 
associated  data  may  be  gathered  and  sorted  in  a  user-defined  way.  This  will  allow 
for  easier  access  to  collected  IPB  and  other  important  data.  (In  Future  Spirals) 
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•  Tagging  data  objects  that  are  displayed  upon  the  map  will  allow  the  team  member  to 
easily  hide/show  the  information  based  upon  a  user  defined  tag.  (In  Future  Spirals) 

•  Allowing  the  user  to  create  a  hierarchy  of  tagging  elements  will  better  allow  them  to 
organize  and  categorize  data  in  multiple  useful  ways.  This  will  allow  for  easier 
access  to  associated  data  based  upon  the  way  the  user  and  team  works.  (In  Future 
Spirals) 

Scope:  User  to  COA  Sketeh  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  A  project  is  open  in  COA  Sketch. 

•  At  least  one  Map  Object  has  been  created. 

Triggers:  The  team  member  wishes  to  modify  information  associated  with  a  Map  Object. 
Guarantees: 

•  The  Team  Member  will  be  able  to  update  the  map  object. 

•  Visual  Characteristic  changes  made  will  be  reflected  in  the  Sketch  View. 

•  With  one  or  all  map  objects  associated  with  a  COA  Sketch  Object  selected  in  the 
Sketch  View,  a  user  can: 

o  Modify  associated  COA  Sketch  Object  specific  properties  (See  use  case  User 
views/Edits  COA  Properties  in  Plan  COA  Use  Cases  Spiral  One  and  editing 
mission  analysis  objects  in  Mission  Analysis  Use  Cases) 
o  Cut 
o  Copy 

o  Paste  -  Default  for  paste  is  paste  a  copy  of  the  entire  COA  Sketch  Object  and 
all  the  selected  shapes  associated  with  it. 
o  Delete  Map  Objects  associated  with  COA  Sketch  Object 
o  Set  the  map  properties  of  all  selected  shapes: 

■  Latitude,  Longitude  of  location(s)  (by  moving,  rotating,  resizing) 
o  fill  color 
o  fill  transparency 
o  border  style 
o  border  color 
o  border  width 
o  border  transparency 

o  minimum  /  maximum  zoom  levels.  If  zoomed  in  any  closer  than  the 
maximum  level,  the  object  will  be  hidden.  If  “zoomed  out”  any 
further  than  the  minimum  level,  the  object  will  be  hidden.  Otherwise, 
the  object  is  visible.  If  neither  is  set,  the  object  is  always  visible, 
o  (shape  is  intentionally  left  off  the  list  because  a  shape  is  selected  when 
placing  a  map  object  on  the  sketch  view) 

•  To  resize  a  Map  Object(s),  the  user  must  have  the  Map  Object(s)  that  is/are  being 
resized  selected. 


B-68 


•  To  paste  a  copy  of  the  shape(s)  with  a  new  CO  A  Sketch  object  (not  a  copy  of  the 
COA  Sketch  Object)  or  to  paste  a  copy  of  the  shape(s)  and  associate  it  with  an 
existing  COA  Sketch  Object,  requires  a  “paste  special”  feature. 

•  Tag  information  added  will  update  the  Sketch  View  depending  upon  what  tags  are 
being  hidden/shown. 

•  Tag  information  added  will  update  the  Sketch  View  if  a  tag  is  added  has  visual 
characteristics  associated  with  it  and  these  changes  are  accepted  by  the  team 
member. 

•  All  tags  added  to  the  system  will  be  available  for  all  users  to  view  and  re-use. 

•  When  the  tag  is  added,  it  will  be  made  readily  available  for  use  by  other  objects 
within  the  system. 

•  If  the  tag  already  exists  within  the  system,  the  object  will  also  exist  within  the  created 
hierarchy  for  that  tag. 

•  If  a  tag ’s  hierarchy  is  modified,  then  all  objects  with  that  tag  will  also  inherit  that 
hierarchy. 

•  The  team  member  will  be  able  to  view  all  tags  associated  with  the  plan  element  or 
Generic  Object. 

•  If  a  tag  is  removed  from  the  plan  element,  the  tag  may  still  exist  within  the  system  if 
other  plan  elements  of  Generic  Objects  are  utilizing  it. 

•  If  a  tag  is  removed  from  the  system,  all  other  objects  associated  with  that  tag  will  no 
longer  have  that  association. 

•  If  the  tag  already  existed,  the  plan  element  will  take  on  the  characteristics  of  that  tag. 

•  If  the  tag  is  edited  and  has  other  objects  associated  with  it,  depending  upon  user 
choices,  the  tag  will  become  a  brand  new  tag  or  all  the  objects  will  be  associated  to 
the  new  tag  name. 

•  If  the  tag  is  removed,  the  tag  will  only  be  completely  removed  from  the  system  if  there 
are  no  other  objects  associated  with  the  tag. 

Main  Success  Scenario: 

1 .  The  user  indicates  the  desire  to  change  a  map  specific  property  of  a  map  object. 

2.  The  system  displays  the  current  settings  for  the  properties  of  the  map  object 

3.  The  user  updates  a  property 

4.  The  system  updates  the  display  of  the  map  object  on  the  Sketch  View  to  reflect  the 
new  property 

4.1.  If  the  object  is  resized  or  moved  and  associated  with  a  target  type,  the  system 
queries  target  DB.  (See  targeting  use  cases  in  TargetingUseCase) 

Requirements: 

2. COA  Sketch  shall  allow  the  user  to  edit  objects  on  a  map  view. 


Use  Case  4.6:  Team  Member  Hides/Shows  Map  Objects 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  wish  to  view  the  objects  on  the  Sketch  View  in 
order  to  better  understand  the  plan  or  aid  in  different  processes  within  the  Joint  Air 
Estimation  Process.  Because  of  this,  the  Team  Member  or  Reviewer  may  wish  to 
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filter  the  Sketch  View  in  multiple  ways.  The  system  should  allow  the  operator  to  hide 
or  show: 

•  Individual  CO  A  Sketch  objects  independently 

•  Objects  by  categories 

•  All  map  objects  designated  by  particular  shapes. 

•  All  map  objects  designated  by  icons. 

•  All  map  objects  associated  with  a  particular  target  type. 

•  Individual  Course  of  Action  (CO A)  and  its  associated  objects 

•  All  map  objects  designated  by  a  Strategy  Plan  Level  (See  Use  Case  4.1:  Team 
Member  Sets  Default  Visual  Appearance  by  Category  or  Strategy  Plan  Level  for 
list  of  levels) 

•  Individual  strategy  elements  and  their  children. 

•  COA  Sketch  object  based  upon  a  user-defined  tag.  (In  Future  Spirals) 

•  Map  objects  related  to  another  map  object  (In  Future  Spirals) 

•  All  but  the  selected  Item(s).  (In  Future  Spirals) 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 
Primary  Actor:  Team  Member 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

•  The  Sketch  View  is  open. 

•  There  is  at  least  one  object  of  the  type  desired  to  be  shown/hidden  on  the  Sketch 
View. 

Triggers:  The  Team  Member  wishes  to  show  or  hide  something  displayed  in  the  Sketch 
View. 

Guarantees: 

•  The  object(s)  selected,  in  the  catego  ry,  with  a  specific  shape,  or  with  a  specific  ico  n 
will  be  hidden  or  shown. 

•  Hiding  the  object(s)  will  not  remove  the  data  from  the  COA  Sketch  System. 

•  As  a  project  is  p  layed,  objects  that  are  hidden  will  remain  hidden  even  when  they  g  o 
into  the  time  focus  of  the  play  through. 

Main  Success  Scenario: 

1 .  The  user  toggles  visibility  of  a  selected  Map  Object. 

2.  The  system  hides/reveals  the  object  affected  by  the  user  selection. 

Alternative  1:  The  User  hides/shows  Category 

1 .  The  user  toggles  visibility  of  a  Category. 

2.  The  system  hides/reveals  the  objects  in  the  category  affected  by  the  user  selection. 
Alternative  2:  The  User  hides/shows  all  Map  Objects  with  a  specific  shape 

1 .  The  user  toggles  visibility  of  a  shape.  Custom  polygon  shapes  will  be  grouped 
together  as  one  shape  type. 

2.  The  system  hides/reveals  the  objects  with  the  shape  of  the  user  selection. 

Alternative  3:  The  User  hides/shows  all  Map  Objects  with  a  specific  icon 

1 .  The  user  toggles  visibility  of  an  icon. 

2.  The  system  hides/reveals  the  objects  with  the  icon  of  the  user  selection. 
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Alternative  4:  The  User  hides/shows  all  Map  Objects  associated  with  a  specific  target 
type 

1 .  The  user  toggles  visibility  of  an  icon. 

2.  The  system  hides/reveals  the  objects  with  the  icon  of  the  user  selection. 

Alternative  5:  The  User  hides/shows  all  Map  Objects  associated  with  a  specific  COA 

1 .  The  user  toggles  visibility  of  all  Map  Objects  associated  with  a  COA. 

2.  The  system  hides/reveals  the  objects  associated  with  the  selected  COA. 

Alternative  6:  The  User  hides/shows  all  Map  Objects  of  a  Specified  Strategy  Plan  Level 

1 .  The  user  toggles  visibility  of  all  Map  Objects  of  a  specific  Strategy  Plan  Level. 

2.  The  system  hides/reveals  the  objects  associated  with  the  selected  level. 

Alternative  7:  The  User  hides/shows  all  children  of  a  Specified  Strategy  Element 

1 .  The  user  toggles  visibility  of  all  children  of  a  specific  Strategy  Element. 

2.  The  system  hides/reveals  the  children  objects  associated  with  the  selected  strategy 
element. 

Alternative  8:  The  User  hides/shows  all  objects 

1 .  The  user  chooses  to  hide  or  show  the  visibility  of  all  objects. 

2.  The  system  hides/reveals  all  objects. 

Requirements: 

2. COA  Sketch  shall  allow  the  user  to  edit  objects  on  a  map  view. 


Use  Case  4.7:  Team  Member  Reorders  the  Map  Group  Layers 

User  Story: 

•  The  Sketch  View  contains  various  groups  of  information.  Because  these  groups 
are  ordered  (layered),  they  could  potentially  block  the  information  on  lower 
groups  on  the  map  if  they  reside  at  the  same  location.  The  user  may  wish  to  view 
the  obstructed  data  without  hiding  the  groups  blocking  it.  To  do  this,  the  user  can 
reorder  the  groups  to  bring  map  objects  from  lower  on  the  map  to  a  more  visible 
position. 

•  User  defined  tags  can  be  used  to  create  new  groups  (In  Future  Spirals) 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 

Support  Actors:  COA  Sketch 

Preconditions:  Map  Sketch  View  is  open. 

Triggers:  Obstructed  data  needs  to  be  viewed  without  hiding  the  other  groups. 

Guarantees: 

•  Groups  are  the  categories,  strategy  plan  levels,  and  user  defined  tags.  (VFDD  3  - 
Layers)  (In  Future  Spirals) 

•  The  contents  of  the  group  will  not  be  altered. 

•  The  groups  moved  will  be  positioned  at  the  correct  location  in  the  group  ordering. 

•  Map  objects  that  may  be  in  more  than  one  group  will  be  displayed  with  its  highest 
(most  on  top)  group. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  reorder  the  display  of  groups  (layers) 

2.  The  system  displays  the  current  group  order 
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3.  The  user  moves  a  group  to  the  new  location. 

4.  The  system  updates  the  Sketch  View  to  reflect  the  new  order. 

Requirements: 


Use  Case  4.8:  Team  Member  Zooms  In/Out  on  Sketch  View 

User  Story  /  Context  of  Use: 

•  The  team  member  or  reviewer  will  want  to  get  a  closer  view  of  the  map  for  more 
detailed  planning  and  layout  of  Map  Objects.  The  team  member  or  reviewer  will  also 
want  to  get  farther  away  to  get  a  broader  view  of  the  Map  Objects  in  the  plan. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Team  member,  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  The  Sketch  View  is  open. 

Triggers:  The  team  member  or  reviewer  wants  to  get  closer  or  farther  away  view  of  the  map. 

Guarantees: 

•  The  maps  appearance  will  reflect  the  change  in  zoom  level. 

•  Map  shapes  will  not  change  geographic  location  based  on  zoom  level. 

Main  Success  Scenario: 

1 .  The  user  uses  the  zoom  in/out  options  within  COA  Sketch. 

2.  The  system  zooms  in  or  out  by  one  step  with  the  same  center  point 
Alternative  1:  User  Selects  Area  to  Zoom  In  On 

1 .  The  user  selects  an  area  on  the  map  to  zoom  in 

2.  The  system  re-centers  the  map  to  the  center  of  the  selected  region  and  zooms  in  to  the 
zoom  level  to  include  only  the  selected  region. 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 


Use  Case  4.9:  Team  Member  Pans  Sketch  View 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  wish  to  view  different  regions  on  the  Map 

Sketch  View  in  order  to  better  understand  the  plan  or  aid  in  different  processes  within 
the  Joint  Air  Estimation  Process.  To  accomplish  this,  they  might  want  to  move  to 
include  other  areas  on  the  map  or  to  change  the  center  point  of  the  map. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 
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•  The  Sketch  View  is  open. 

Triggers:  The  team  member  or  reviewer  wants  to  view  another  part  of  the  map  at  the  same 
zoom  level. 

Guarantees: 

•  The  maps  appearance  will  reflect  the  change  of  center  point. 

•  Map  Objects  will  not  change  geo  graphic  location  due  to  the  m  ap  cente  r  point 
changing. 

Main  Success  Scenario: 

1 .  The  user  selects  the  pan  option  and  indicates  how  the  map  should  move 

2.  The  system  updates  the  view  to  match  the  user  input. 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user 
for  better  enhancing  the  display  of  the  plan. 


Use  Case  4.10:  Team  Member  Changes  Map  Style 

User  Story  /  Context  of  Use: 

•  The  team  member  or  reviewer  might  want  to  change  the  appearance  of  the  map. 
Example  styles  are:  Satellite  images,  street  maps,  hybrid,  (a  mix  of  satellite  images 
and  street  maps),  and  a  gridline  map. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  The  Sketch  View  is  open. 

Triggers:  The  team  member  or  reviewer  wants  to  view  the  map  in  a  different  style. 

Guarantees: 

•  The  m  aps  appearanc  e  will  be  cha  nged  to  th  e  selected  style,  if  the  im  age  data  is 
available. 

•  Map  shapes  will  not  change  geographic  location  due  to  the  map  style  changes 

•  Map  center  point  and  zoom  level  will  not  change  due  to  the  style  change. 

Main  Success  Scenario: 

1 .  The  user  selects  the  desired  map  style  for  the  Sketch  View. 

2.  The  system  displays  the  map  in  the  selected  style. 

Alternative  1:  No  imagery  Data  Available  at  location 

1 .  The  user  selects  to  view  a  style  that  includes  imagery  that  is  not  available  for  the 
current  area  displayed  on  the  map. 

2.  The  system  informs  the  user  the  imagery  is  not  available  and  remains  in  previous 
style 

Alternative  1:  No  imagery  Data  Available  at  current  Zoom  Level 

1 .  The  user  selects  to  view  a  style  that  includes  imagery  that  is  not  available  for  the 
current  area  displayed  on  the  map  map 

2.  The  system  informs  the  user  the  imagery  is  not  available  at  the  current  zoom  level 

3.  The  user  zooms  out  in  the  Sketch  View 
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4.  The  system  displays  the  satellite  imagery  when  the  user  reaehes  a  zoom  level  where 
imagery  exists. 

Requirements: 

1 .  COA  Sketeh  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 


Use  Case  4.11:  User  Imports  Map  Layer  onto  Map 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  wish  to  import  a  map  layer  compatible  with  the 
map  server  to  enhance  the  Sketch  View.  This  will  help  the  team  maintain  situational 
awareness  and  will  lead  to  a  better  understanding  of  the  COA  being  developed. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

•  The  Sketch  View  is  open. 

Triggers:  Team  Member  or  Reviewer  would  like  to  add  a  map  server  layer  onto  the  map. 

Guarantees: 

•  The  system  will  allow  com  patible  map  layers  of  the  m  ap  server  to  be  imported  and 
displayed  on  the  map. 

•  Depending  upon  the  zoom  level  displayed  in  the  geographic  region,  some  map  layer 
data  may  only  be  useful  when  displayed  at  specific  zoom  levels.  Because  of  this,  the 
team  members  should  be  able  to  set  what  these  levels  are.  This  will  aid  in  a  proper 
filter  of  the  map  to  help  with  situational  awareness  and  reduce  cognitive  load. 

•  The  system  will  display  and  hide  a  map  layer  according  to  the  set  zoom  level. 

Main  Success  Scenario: 

1 .  The  user  selects  to  import  a  map  layer  and  the  zoom  level  it  is  to  be  displayed. 

2.  The  system  requests  location  of  layer 

3.  The  user  sets  location  of  layer  to  import. 

4.  The  system  imports  the  layer  into  the  map  server  so  that  it  is  available  for  selection  on 
the  map 

Alternative  1:  Unable  to  Import  Map  Layer 

4.  The  system  alerts  the  user  that  the  layer  can  not  be  imported. 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 


Use  Case  4.12:  User  Updates  Minimum  and  Maximum  Zoom  Level  of 
Map  Layer 

User  Story  /  Context  of  Use: 
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•  Depending  upon  the  zoom  level  displayed  in  the  geographic  region,  some  map  layer 
data  may  only  be  useful  when  displayed  at  specific  zoom  levels.  Because  of  this,  the 
team  members  should  be  able  to  set  what  these  levels  are.  This  will  aid  in  a  proper 
filter  of  the  map  to  help  with  situational  awareness  and  reduce  cognitive  load. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

•  The  Sketch  View  is  open. 

•  At  least  one  map  layer  has  been  imported. 

Triggers:  Team  Member  or  Reviewer  would  like  to  adjust  the  zoom  levels  a  map  layer  is 

visible  on  the  map. 

Guarantees: 

•  The  system  will  disp  lay  and  hide  a  m  ap  layer  according  to  the  set  zoo  m  level.  If 
zoomed  in  any  closer  than  the  maximum  level,  the  object  will  be  hidden.  If  “zoom  ed 
out”  any  further  than  the  minimum  level,  the  object  will  be  hi  dden.  Otherwise,  the 
object  is  visible.  If  neither  is  set,  the  object  is  always  visible. 

•  If  the  layer  is  set  to  be  always  shown  or  always  hidden,  the  zoom  level  values  will  be 
updated,  however  the  always  shown  or  always  hidden  setting  will  take  precedent  over 
the  zoom  settings  for  display  of  the  layer. 

Main  Success  Scenario: 

1 .  The  user  selects  to  set  the  zoom  levels  a  map  layer  is  visible. 

2.  The  system  displays  the  current  minimum  and  maximum  zoom  levels 

3.  The  user  updates  the  minimum  and  maximum  zoom  levels  for  the  layer 

4.  The  system  hides  or  shows  the  map  layer  depending  on  the  current  zoom  level  and 
the  set  visible  levels. 

Alternative  1:  Layer  is  set  to  always  hide  for  user 

5.  The  zoom  levels  are  updated,  but  the  layer  is  still  not  visible  since  the  user  has  set  it 
to  always  be  hidden. 

Alternative  2:  Layer  is  set  to  always  show  for  user 

6.  The  zoom  levels  are  updated,  but  the  layer  is  visible  regardless  of  the  current  zoom 
level  since  the  user  has  set  it  to  always  be  shown. 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 


Use  Case  4.13:  Team  Member  Shows  /  Hides  a  Map  Layer 

User  Story  /  Context  of  Use: 

•  A  team  member  wants  to  show  or  hide  a  layer  in  the  map.  They  may  want  to  see 
more  details  of  the  layer  by  showing  it,  or  hide  the  layer  so  they  can  focus  on  other 
pieces  of  data. 

Scope:  User  to  COA  Sketch  Interaction,  Applies  to  user  view  only 
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Level:  User  Goal 

Primary  Actor:  Team  Member,  Review 
Supporting  Actors:  CO  A  Sketch 
Preconditions: 

•  A  project  is  open  in  CO  A  Sketch 

•  The  Sketch  View  is  open 

Triggers:  The  user  wishes  to  hide  or  show  a  layer. 

Guarantees: 

•  The  selected  layer(s)  will  be  shown,  hidden,  or  use  zoom  levels. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  show\hide  map  layer(s). 

2.  The  system  displays  the  list  of  layer(s)  that  can  be  shown  or  hidden.  Layers  that  are 
not  currently  within  the  zoom  range  are  indicated.  It  additionally  indicates  if  a  layer 
is  set  to  be  always  shown,  always  hidden,  or  use  zoom  levels. 

3.  The  user  selects  layer(s)  to  show,  hide,  or  use  zoom  levels. 

4.  The  system  updates  the  map  to  show,  hide,  or  use  zoom  levels  for  the  selected 
layer(s). 

Requirements: 


Use  Case  4.14:  Team  Member  Views  Latitude/Longitude  Coordinates 

User  Story  /  Context  of  Use: 

•  A  team  member  may  wish  to  center  or  contain  certain  coordinates  on  the  map  with  a 
shape  or  icon. 

•  A  team  member  or  reviewer  may  wish  to  see  what  coordinates  an  already  existing 
shape  or  icon  resides. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Team  Member,  Review 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch 

•  The  Sketch  View  is  open 

Triggers:  The  user  wishes  to  see  coordinates  on  the  map 

Guarantees: 

•  The  coordinates  in  latitude/longitude  will  default  to  being  represented  using  N,S,E,W 
instead  of  +-. 

Main  Success  Scenario: 

5.  The  user  chooses  to  see  the  coordinates  of  a  location  on  the  map. 

6.  The  system  displays  the  coordinates  of  the  location  to  the  user 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 
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Use  Case  4.15:  Team  Member  Hides/  Shows  Labels 

User  Story  /  Context  of  Use: 

•  The  Team  Member  has  the  option  of  displaying  labels  on  the  objects  on  the  map.  This 
will  help  the  team  maintain  situational  awareness  and  will  lead  to  a  better 
understanding  of  the  COA  being  developed. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

•  The  Sketch  View  is  open. 

•  There  is  at  least  one  map  object  on  the  Sketch  View 

Triggers: 

•  The  Team  Member  would  like  to  see  labels  on  the  shapes  to  help  distinguish  what  they 
are. 

Guarantees: 

•  The  COA  Sketch  Object  name  associated  with  the  Map  Object  will  be  displayed  in 
the  label. 

•  If  a  COA  Sketch  Object  has  more  than  one  map  object  associated  with  it,  the  same 
label  will  be  displayed  on  all  those  map  objects. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  show  the  labels  of  all  objects  visible  on  the  Sketch  View. 

2.  The  system  displays  the  name  of  all  the  COA  Sketch  Objects  associated  with  the 
currently  visible  Map  Objects  on  the  map. 

Alternative!:  Hide  Labels 

1 .  The  user  chooses  to  hide  the  labels  of  all  objects  visible  on  the  Sketch  View. 

2.  The  system  hides  the  labels  of  all  the  COA  Sketch  Object  on  the  map. 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 


Use  Case  4.16:  Team  Member  Views/Hides  Legend  for  Sketch  View 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  require  a  list  of  used  map  properties  set  in  the 
preferences  (See  Use  Case  4.1:  Team  Member  Sets  Default  Visual  Appearance  by 
Category  or  Strategy  Plan  Level  for  list  of  available  map  properties)  that  are 
displayed  on  the  current  Sketch  View.  This  will  aid  the  Team  Member  or  Reviewer 
in  better  understanding  of  what  the  Sketch  View  is  attempting  to  convey. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 
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•  A  project  is  open  in  CO  A  Sketch. 

•  The  Sketch  View  is  open. 

•  There  is  at  least  one  Sketch  Object  on  the  Sketch  View. 

Triggers:  Team  Member  or  Reviewer  would  like  to  see  or  hide  the  legend  for  the  Sketch 
View. 

Guarantees: 

•  The  legend  will  be  displayed/hidden  as  the  user  has  requested 

•  The  legend  will  con  tain  a  desc  ription  of  all  d  efined  m  ap  proper  ty  p  references  o  f 
categories  and  strategy  plan  level  currently  displayed  on  the  Sketch  View. 

•  The  legend  will  contain  a  description  of  user  added  entries. 

•  As  objects  on  the  map  are  hidden  or  displayed,  the  legend  w  ill  update  to  reflect  these 
changes  to  the  Sketch  View. 

•  Unless  changed  by  a  Team  Member,  the  icon  or  shape  will  be  described  in  the  legend 
by  listing  the  user-defined  tags.  If  the  icon  or  shape  represents  a  plan  element  that 
does  not  have  a  tag,  the  name  of  the  plan  element  will  be  displayed. 

Main  Success  Scenario: 

1 .  The  user  toggles  the  Legend  in  the  Sketch  View. 

2.  The  system  hides/reveals  the  Legend  in  the  Sketch  View. 

3.  The  system  filters  the  legend  to  only  show  entries  relating  to  map  objects  that  are 
visible. 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 

Use  Case  4.17:  Team  Member  Adds  Legend  Entry  for  Sketch  View 

User  Story  /  Context  of  Use: 

•  Because  the  user  has  the  option  of  displaying  multiple  types  of  objects  on  the  map, 
the  user  may  add  entries  to  the  legend  to  provide  a  better  short  description  for  the 
different  objects  displayed. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

•  The  Sketch  View  is  open. 

•  There  is  at  least  one  Sketch  Object  on  the  Sketch  View. 

Triggers:  The  Team  Member  wishes  to  add  the  way  a  map  property  is  described  in  the 
legend. 

Guarantees: 

•  The  legend  will  d  isplay  the  m  ap  property(ies)  in  the  legend  with  the  de  scription  the 
user  has  designated. 

•  A  legend  entry  can  have  more  than  one  map  property  to  describe  a  single  entry. 

Main  Success  Scenario: 

1 .  The  user  selects  to  add  a  legend  entry. 
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2.  The  system  prompts  user  to  enter  the  map  property/properties  and  what  it  is  denoting. 

3.  The  user  adds  the  information  and  indicates  completion 

4.  The  system  displays  the  new  entry  in  the  legend.  The  entry  is  not  attached  to  any 
specific  objects,  so  it  will  remain  in  the  legend  independent  of  what  objects  are 
visible 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 


Use  Case  4.18:  Team  Member  Edits  Legend  Entry  for  Sketch  View 

User  Story  /  Context  of  Use: 

•  Because  the  user  has  the  option  of  displaying  multiple  types  of  objects  on  the  map, 
the  user  may  edit  entries  in  the  legend  to  provide  a  better  short  description  for  the 
different  objects  displayed. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

•  The  Sketch  View  is  open. 

•  There  is  at  least  one  entry  in  the  legend. 

Triggers:  The  Team  Member  wishes  to  edit  the  way  a  map  property  is  described  in  the 
legend. 

Guarantees: 

•  The  legend  will  display  the  map  property/properties  in  the  legend  with  the  description 
the  user  has  designated. 

•  A  legend  entry  can  have  more  than  one  map  property  to  describe  a  single  entry. 

•  An  edited  legend  entry  will  a  Iways  ref  erence  the  sam  e  objects;  it  will  appear  and 
disappear  in  the  legend  as  the  objects  are  visible 

Main  Success  Scenario: 

1 .  The  user  selects  to  edit  a  legend  entry. 

2.  The  system  displays  the  entry  as  it  currently  exists. 

3.  The  user  changes  the  map  property/(ies)  or  description. 

4.  The  system  displays  the  updated  entry  in  the  legend  if  appropriate.  The  entry  is  only 
changed  for  the  current  user. 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 


Use  Case  4.19:  Team  Member  Deietes  Legend  Entry  for  Sketch  View 

User  Story  /  Context  of  Use: 
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•  Because  the  user  has  the  option  of  displaying  multiple  types  of  objects  on  the  map, 
the  user  may  find  it  necessary  to  delete  entries  in  the  legend.  This  will  aid  the  Team 
Member  or  Reviewer  in  better  understanding  of  what  the  Sketch  View  is  attempting 
to  convey. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

•  The  Sketch  View  is  open. 

•  There  is  at  least  one  entry  in  the  legend. 

Triggers:  The  Team  Member  wishes  to  delete  an  entry  in  the  legend. 

Guarantees: 

•  The  legend  will  remove  the  legend  entry. 

Main  Success  Scenario: 

1 .  The  user  selects  to  delete  a  legend  entry. 

2.  The  system  requests  deletion  confirmation 

3.  The  user  confirms  deletion 

4.  The  system  deletes  the  entry  in  the  legend. 

Alternative  1:  User  cancels  deletion 

3.  The  user  cancels  deletion 

4.  The  system  returns  to  its  previous  state 
Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user  for  better 
enhancing  the  display  of  the  plan. 


Use  Case  4.20:  Team  Member  Restores  Legend  for  Sketch  View 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  wish  to  restore  to  the  default  legend  containing 
categories  and  strategy  play  levels  set  in  the  preferences  (See  Use  Case  4.1:  Team 
Member  Sets  Default  Visual  Appearance  by  Category  or  Strategy  Plan  Level).  This 
will  aid  the  Team  Member  or  Reviewer  in  better  understanding  of  what  the  Sketch 
View  is  attempting  to  convey. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  A  project  is  open  in  COA  Sketch. 

•  The  Sketch  View  is  open. 

•  There  is  at  least  one  Sketch  Object  on  the  Sketch  View. 

Triggers:  Team  Member  or  Reviewer  would  restore  the  legend  for  the  Sketch  View. 

Guarantees: 
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•  The  legend  will  conta  in  everything  in  th  e  preference  settings  that  is  cu  rrently  being 
displayed  on  the  map. 

Main  Success  Scenario: 

1 .  The  user  selects  to  restore  the  legend. 

2.  The  system  requests  confirmation  on  losing  changes  to  legend 

3.  The  user  confirms  losing  changes 

4.  The  system  restores  the  legend  to  its  default  view. 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the  user 
for  better  enhancing  the  display  of  the  plan. 


Use  Case  4.21:  Locate  COA  Sketch  Object  in  the  Synch  View 

User  Story:  When  the  timing  of  a  plan  gets  long,  bars  on  the  Synch  View  may  not  be 
visible  and  can  get  hard  to  find.  It  would  be  useful  to  have  the  system  scroll  to  the  bar 
associated  with  the  COA  Sketch  object  selected  in  Sketch  View. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Team  Member,  Reviewer 
Support  Actors:  COA  Sketch 
Preconditions: 

•  Sketch  View  is  open. 

•  There  is  at  least  one  map  object  on  the  Sketch  View 

Triggers:  The  user  would  like  to  locate  the  selected  map  object’s  associated  bar  in  the 
Synch  View. 

Guarantees: 

•  The  Synch  View  will  scroll  to  the  selected  bar. 

•  If  the  Synch  View  is  closed,  it  will  automatically  open. 

•  If  the  COA  Sketch  object  is  hidden  in  the  Synch  View,  the  object  will  be  shown. 

•  No  timing  data  will  be  affected. 

Main  Success  Scenario: 

1 .  The  user  selects  a  map  object  on  the  Sketch  View,  (see  Use  Case  4.4:  Team 
Member  Selects  Map  Object  on  Sketch  View) 

2.  The  user  selects  to  scroll  to  the  COA  Sketch  Object  in  the  Synch  View 

3.  The  system  centers  the  Synch  View  on  the  bar  representing  that  COA  Sketch 
Object 

Alternative  1:  Synch  View  Not  Open 

3.  The  system  determines  the  Synch  View  is  closed  and  opens  it  before  centering  on 
the  bar  representing  that  COA  Sketch  Object. 

Alternative  2:  COA  Sketch  Object  Hidden 

3.  The  system  determines  the  Synch  View  currently  has  the  COA  Sketch  Object 
hidden,  so  it  un-hides  the  category  containing  the  COA  Sketch  Object  before 
centering  on  the  bar  representing  that  COA  Sketch  Object. 

Alternative  3:  COA  Sketch  Object  Collapsed 

3.  The  system  determines  the  Synch  View  currently  has  the  COA  Sketch  Object  not 
visible  because  its  parent  is  collapsed,  so  it  expands  the  hierarchy  containing  the 
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CO  A  Sketch  Object  before  centering  on  the  bar  representing  that  CO  A  Sketch 
Object. 

Requirements: 

1 .  COA  Sketch  shall  have  several  display  features  available  to  the 
user  for  better  enhancing  the  display  of  the  plan. 
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Collaborative  Environment  Use  Cases 


1.  Collaborative  Data  Manipuiation  Scenarios 

COA  Sketch  is  based  upon  being  a  collaborative  tool.  Some  goals  of  this  tool  is  to  allow 
collaboration  and  modification  of  mission  data  at  any  level,  without  applying  unwanted  rule  sets 
on  the  user  with  respect  to  what  data  they  are  allowed  to  edit  and  when.  By  allowing  users  to 
modify  data  all  the  way  down  to  the  attribute  level,  this  frees  the  team  to  be  able  to  collaborate 
and  plan  in  ways  they  may  not  have  been  able  to  in  the  past.  This  new  functionality  will 
hopefully  aid  the  current  planning  process  by  providing  more  collaboration,  more  easily 
accessible  and  real-time  data  as  it  is  being  analyzed  and  determined.  This  does  provide  some 
interesting  scenarios  for  the  development  team  on  potential  conflictions  of  data  and  system 
interaction.  This  document  will  aid  the  COA  Sketch  design  team  in  determining  different  options 
to  aid  us  in  selecting  best  choice  for  implementation. 

Some  requirements: 

•  COA  Sketch  shall  allow  multiple  users  to  modify  different  attributes  and  fields  in  a 
project  simultaneously. 

•  COA  Sketch  shall  lock  data  for  modification  at  the  lowest  level  (attribute  or  field)  in 
order  to  reduce  locking  data  that  other  users  may  want  to  modify. 

•  COA  Sketch  shall  inform  users  of  what  fields  have  been  modified,  added,  or  removed. 

•  COA  Sketch  shall  automatically  save  modifications  to  projects. 

•  COA  Sketch  shall  provide  individual  users  a  ways  to  “undo”  and  “redo”  changes  made 
by  that  user  while  providing  a  way  to  consider  changes  made  by  other  users. 

•  COA  Sketch  shall  provide  user  a  way  to  “undo”  and  “redo”  changes  made  by  multiple 
users 

•  COA  Sketch  shall  release  modification  locks  on  data  when  user  indicates  that 
modification  has  been  completed. 

•  COA  Sketch  shall  provide  an  alternative  way  to  release  modification  locks  on  data. 


Note:  Italicized  text  indicates  scenarios  that  we  believe  will  be  rarely  used  functionality. 

Normal  Change  Case 

We  have  attempted  to  indicate  throughout  the  document  how  other  users  will  view  locks  and 
changes.  This  may  not  have  been  pushed  through  to  each  scenario.  Please  make  the  assumption 
that  any  locks  on  any  data  will  be  visually  indicated  to  all  users.  Please  make  the  assumption  that 
any  changes  (modifications,  additions,  deletions)  will  also  be  visually  indicated  to  all  users. 

1 .  User- A  starts  to  change  Field-X 

2.  All  users  who  currently  view  Field-X  or  view  field-X  before  step  6  are  notified  (via  a 
subtle  signal:  the  text  field  background  turns  gray)  that  Field-X  is  being  changed. 

3.  The  field  is  locked  for  editing.  Users  other  than  User-A  can’t  make  changes  to  Field-X. 
(For  exceptions,  see  scenarios  in  section  0,  Error!  Reference  source  not  found.) 

4.  User-A  completes  changes  to  Field-X 

5.  The  system  stores  the  changes  and  adds  the  change  to  a  “change  history”. 
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6.  Users  viewing  Field-X  immediately  sees  the  change  User-A  made  to  Field-X 

7.  Users  other  than  User-A  that  are  viewing,  or  do  view,  Field  X  are  notified  (via  a  subtle 
signal)  that  Field-X  has  (or  has  not)  been  modified,  (i.e:  Field  text  changes  to  Bold. 

There  would  also  be  a  user  specified  amount  of  time  the  text  would  remain  bold  to 
indicate  that  the  change  was  “new”  before  reverting  back  to  a  normal  font.) 

8.  Users  viewing  Field-X  receive  indication  that  they  may  once  again  make  changes  to 
Field-X.  (Field  is  unlocked) 

9.  All  users  have  access  to  the  change  history  so  they  can  “revert”  changes. 

Lock  Management  Concepts 
Lock  Time  Out 

System  preferences  should  include  the  ability  to  set  a  lock  time  out.  This  option  allows  for 
locks  to  time  out  with  less  obtrusive  messages  while  still  providing  the  ability  to  potentially 
salvage  unsaved  changes. 

1.  See  steps  1-3  of  Normal  Change  Case. 

2.  User-A  does  not  indicate  that  changes  to  Field-X  are  complete,  therefore  the  system  does  not 
save  changes  or  release  locks. 

3.  User-A  has  been  inactive  (or  doesn’t  type  or  interact  with  system)  for  a  user-defined  amount 
of  time.* 

4.  User-A  is  informed  by  a  subtle  indicator  that  the  lock  may  be  taken  away  unless  the  user 
takes  action  within  Y  seconds*.  User  A  is  given  these  choices:  Renew  the  lock  by  providing 
changes  or  let  lock  expire. 

4. 1 .  The  user  decides  to  renew  the  lock. 

4.1.1.  User-A  begins  modification  (becomes  active,  or  “types  something”)  of 
Field-X. 

4.1.2.  The  system  recognizes  the  activity  of  User-A  and  automatically  renews 
the  lock. 

4.1.3.  See  step  4  of  normal  change  scenario. 

4.2.  The  user  allows  lock  to  expire  (does  nothing) 

4.2. 1 .  User-A’s  display  of  Field-X  indicates  that  the  user  no  longer  has  the 
lock. 

4.2.2.  All  users  currently  viewing  Field-X  will  receive  indication  that  the  field 
is  no  longer  locked. 

4.2.3.  User-A’s  display  of  Field-X  remains  unchanged  until  another  user  tries 
to  edit  Field-X. 

4.2.3. 1.  No  other  user  edits  Field-X. 

4.2. 3. 1.1.  User-A  can  continue  editing  Field-X  as  if  he  had  never  lost  the 
lock,  thus  keeping  the  previous  changes  even  though  the  lock  timed  out. 

4.2.3. 1 .2.  All  users  currently  viewing  Field-X  will  receive  indication  that  the 
field  is  locked  again  by  User-A. 

4.2. 3. 2.  Another  user  edits  Field-X. 

4.2. 3.2. 1 .  User-A  receives  display  of  a  temporary  Field-Xl  that  contains 
Field-X  just  as  User-A  had  last  modified  it. 


B-84 


4.2. 3.2.2.  User-A  can  decide  to  discard  changes  in  Field-Xl,  edit  Field-Xl, 
or  apply  them 

4.2.3.2.2.1.  User-A  discards  changes. 

4.2. 3. 2.2. 1.1.  Field-Xl  disappears  and  all  changes  to  Field-Xl  are 
lost. 

4.2. 3. 2.2. 2.  User-A  continues  to  edit  Field-Xl. 

4.2.3.2.2.2.1.  Field  X-1  is  updated  to  reflect  User-A’s  modifications. 

4.2. 3. 2.2. 2.2.  Return  to  step  4.2. 3. 2.2 

4.2. 3.2.2. 3.  User-A  tries  to  save  Field  X-1  to  fleld-X 

4.2. 3. 2.2. 3. 1 .  The  system  attempts  to  retrieve  lock  for  field-X 

4.2. 3.2.2. 3. 1.1.  If  lock  is  retrieved, 

4.2. 3. 2.2. 3. 1.1.1.  System  locks  field-X.  All  users  viewing 
field-X  will  receive  visual  indication  that  the  field  is 
locked. 

4.2. 3.2.2. 3. 1.1. 2.  System  saves  data  held  in  field-Xl  over  data 
stored  in  field-X  and  releases  lock. 

4.2. 3.2.2. 3. 1.1. 3.  All  users  viewing  field-X  will  receive  visual 
indication  that  the  field  has  changed  and  that  the 
lock  is  released. 

4.2. 3. 2.2. 3. 1.2.  If  lock  is  not  retrieved, 

4.2. 3.2.2. 3. 1.2.1.  System  informs  user  that  user-B  has  lock. 

4.2. 3. 2.2. 3. 1.2.2.  If  user-A  has  lock  requesting  privileges, 
User-A  can  request  the  lock  from  User-B  (See 
scenario  0,  Request  Lock) 

4.2. 3. 2.2. 3. 1.2. 3.  Otherwise,  user  will  need  to  wait  until  lock 
is  released  by  User-B.  Return  to  step  4.2. 3.2.2 

*  The  system  would  need  to  time  the  lock  for  a  user-defined  Z  seconds,  which  needs  to  be 
at  least  Y  seconds  long.  Once  Z-Y  seconds  have  passed,  the  server  would  alert  the  client 
that  the  lock  may  be  released  soon.  The  client  would  have  Y  seconds  to  detect  activity  by 
User-A  before  further  action  took  place. 

View  lock  holder 

1 .  At  least  one  user  has  locked  at  least  one  field  for  modification. 

2.  All  users  will  receive  a  visual  indication  that  the  field(s)  has  been  locked  by  another  user(s). 

3.  User-A  selects  locked  item(s)/field 

4.  User-A  indicates  they  want  to  see  who  holds  the  lock  on  selected  field(s)/item(s) 

5.  System  displays  lock  holder(s)  for  selected  item(s). 

Request  Lock 

Reason  for  functionality:  The  ability  to  allow  users  to  request  locks  that  are  held  by  other 
users  could  allow  for  longer  “time  outs”,  in  that  a  user  will  have  the  ability  to  not  lose  a 
lock  if  they  step  away  for  a  short  period  of  time.  However,  if  that  short  period  of  time 
becomes  too  long,  for  example,  the  user  leaves  work  for  the  day,  other  users  would  need  to 
have  the  ability  to  release  locks  so  that  work  can  continue.  Because  of  this,  we  need  to 
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consider  what  would  happen  when  that  lock  is  released  to  another  user,  even  in  what 
should  be  a  rare  case  that  the  initial  lock  holder  is  or  was  actively  modifying  the  field  when 
the  lock  was  taken. 

1.  See  steps  1-3  of  Normal  Change  Case. 

2.  User-B  has  ability/permissions  to  request  the  lock,  so  the  system  displays  this  option. 

3.  User-B  chooses  to  request  the  lock. 

4.  User-B  waits  for  indication  that  they  have  the  lock. 

5.  User-A  is  informed  that  User-B  has  requested  the  lock.  User-A  can  do  one  of  the 
following: 

5.1.  User-A  does  nothing 

5.1.1.  After  Y  seconds,  User-A  loses  the  choice  to  deny  the  lock  and  save  changes. 

5.1.2.  User-A ’s  unsaved  changes  are  now  displayed  in  a  temporary  Field-Xl, 
visible  only  to  User-A. 

5. 1.3.  User-A  may  perform  one  of  the  following  actions: 

5. 1.3.1.  Discard  unsaved  changes  displayed  in  Field-Xl 

5. 1.3. 1.1. System  removes  display  of  temporary  Field-Xl  and  data  held  in 
that  field  is  lost. 

5.1.3. 2.  Request  the  lock  back  from  User-B. 

5. 1.3. 2.1.  Return  to  step  3  of  this  scenario,  replacing  User-B  with  User-A 
and  vice  versa. 

5. 1.3. 3.  Wait  until  lock  is  released  and  reclaim ’s  lock  for  editing  on  field-X 
5. 1.3. 3.1. See  steps  in  scenario  0  Lock  Time  Out,  section  4.25. 

5. 1.3.4.  Continue  to  edit field-Xl. 

5. 1.3. 4.1.  The  user  will  be  able  to  continue  editing  in  field-Xl. 

5. 1.3. 4. 2.  Return  to  step  5.1.3 

5.2.  User-A  denies  the  lock  request 

5.2.1.  User-A  may  continue  editing  (return  to  step  3  of  scenario  0,  Normal  Change 
Case) 

5.2.2.  User-B  is  informed  that  the  lock  request  has  been  denied. 

5.3.  User-A  saves  changes  and  relinquishes  lock  to  User-B 

5.3.1.  The  system  saves  the  changes. 

5.3.2.  All  users  viewing  field-X  receive  visual  indication  that  field-x  has  changed. 

5.3.3.  The  system  locks  the  field  for  User-B 

5.3.4.  User-A,  and  all  other  users,  receive  visual  indication  that  the  field  is  locked. 

5.3.5.  User-B  continues  to  modify  (continue  as  User-A  in  step  4  of  the  normal 
change  case). 

5.4.  User-A  discards  changes  and  relinquishes  lock  to  User-B 

5.4.1.  The  system  discards  all  changes  made  by  User-A. 

5.4.2.  User-A  ’s  view  of  Field-X  is  updated  to  reflect  the  last  saved  data. 

5.4.3.  The  system  locks  the  field  for  User-B 

5.4.4.  User-A,  and  all  other  users,  receive  visual  indication  that  the  field  is  locked. 

5.4.5.  User-B  continues  to  modify  (continue  as  User-A  in  step  4  of  the  normal 
change  case). 
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Creating  new  objects 

A  new  object  can  be  defined  as  either  a  new  element  to  a  list,  which  could  be  as  simple  as  a  text 
field,  or  as  complex  as  one  or  multiple  objects  represented  in  a  data  model. 

Add  Object 

1.  User-A  adds  new  Object-X. 

2.  If  applicable,  the  system  will  prompt  user  for  any  required  data  necessary  for  the 
creation  of  Object-X  (The  system  may  also  prompt  for  optional  data  as  well.).  User-A 
will  comply  or  cancel. 

a.  User-A  Complies 

i.  Continue  to  step  3. 

b.  User-A  Cancels 

i.  No  new  object  gets  created.  System  removes  prompt  for  required  data. 

3.  The  system  creates  Object-X.  If  object-X  requires  any  additional  objects  to  exist,  the 
system  creates  those  as  well.  The  object(s)  in  question  will  have  default  values  where 
required  and  will  also  be  instantiated  with  the  required  data,  if  applicable,  indicated  by 
User-A. 

4.  All  users  viewing  displays  that  are  affected  by  new  Object-X  will  immediately  see  the 
Object-X  appear  and  it  is  visually  indicated  as  modified  to  all  users. 


Removing  existing  objects 
Remove  Object 

1 .  User-A  indicates  Object-X  should  be  removed. 

2.  The  system  determines  lock  status  of  any  data  associated  with  Object-X 
(fields/attributes,  children) 

3.  If  edits  are  being  made  to  Object-X  or  its  associated  data, 

3.1.  If  User-A  does  not  have  permission  to  take  the  lock(a)  away 

3.1.1.  The  system  alerts  the  user  of  the  situation  and  does  not  remove  Object-X 

3.2.  If  User-A  has  permission  to  request  a  lock 

3.2.1.  If  the  User-A  chooses  not  to  take  the  locks  away 

3.2. 1 . 1 .  The  object  is  not  deleted  and  the  views  are  not  changed. 

3.2.2.  If  the  User-A  requests  locks  from  other  users  holding  locks  on  Object-X’s 
associated  data 

3.2.2. 1.  See  scenario  0,  Request  Lock.  All  users  who  currently  hold  locks 
would  need  to  comply  with  the  request  made  by  User-A. 

3.2.2. 1 . 1 .  If  users  do  not  comply, 

3.2.2. 1 .1.1.  User-A  is  informed  that  the  object  cannot  be  removed. 

3.2. 2. 1.2.  If  users  comply, 

3.2.2. 1.2.1.  Continue  to  step  4.1 

4.  If  edits  are  not  being  made, 

4. 1 .  The  system  locks  Object-X  and  all  associated  data/objects  for  User-A. 

4.2.  The  system  determines  what  associated  data  also  should  be  removed  along  with 
Object-X. 
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4.3.  The  system  immediately  deletes  Object  X  and  determined  associated 
data/objects  ready  for  removal. 

4.4.  Views  of  all  users  are  updated  to  reflect  that  the  object  was  removed. 

4.5.  Where  possible,  views  should  reflect  the  removal  of  the  object  and  not  just 
remove  it. 


Viewing  changes 
Opening  a  project 

The  idea  of  this  concept  is  to  allow  users  to  just  use  the  change  history  if  they  want  to  know 
what  has  changed  since  they  last  logged  in  (or  any  other  defined  amount  of  timing). 
Viewing  visual  change  modification  would  then  consist  ONLY  of  changes  made  by  users 
while  viewing  a  project. 

This  approach  will  allow  the  visualizations  to  be  established  in  a  rule  set  more  easily 
understood  by  users,  but  also  allow  for  follow  on  spirals  to  be  able  to  build  upon  this  to 
develop  a  more  intricate  use  of  viewing  change  notifications  for  users  between  sessions  as 
well. 

1.  User-A  opens  COA  Sketch. 

2.  User-A  opens  an  existing  project  within  COA  Sketch 

3.  The  system  determines  User-A  preferences  for  viewing  existing  changes. 

4.  If  ability  to  view  change  notifications  is  disabled,  do  nothing. 

5.  The  system  will  display  all  data  changes  made  to  user- A  for  the  data  required  for 
requested  views  open  during  the  session. 


Mark  as  Viewed 

If  time  does  not  permit  for  implementation,  this  functionality  may  be  slated  for  future 
spirals. 

1. The  “normal  change  case",  “Remove  Object",  or  “Add  object"  scenario  has  occurred 

and  some  object  or  Field  is  being  displayed  as  “new"  or  “changed"  or  “deleted". 

2.  User-B  selects  the  data  and  marks  it  as  “viewed". 

3.  The  system  displays  the  data  as  “no  longer  new",  “no  longer  newly  changed",  or 

removes  the  “deleted"  indicator. 

Mark  all  data  in  a  View  as  “viewed” 

1.  The  “normal  change  case”,  “Remove  Object”,  or  “Add  object”  scenario  has  occurred 
and  some  object  or  Field  is  being  displayed  as  “new”  or  “changed”  or  “deleted”  within 
a  view. 

2.  Step  one  may  have  occurred  multiple  times,  so  that  at  least  1  or  more  changes  are 
indicated  by  the  system  to  User-B  in  the  same  view. 

3.  User-B  indicates  that  all  change  notifications  for  that  view  be  reset. 
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4.  System  sets  all  data  within  view  as  “viewed”,  thereby  removing  the  visual  ehange 
notifieations  from  that  view.  All  other  views  in  which  the  data  is  displayed  will  also 
have  the  visual  change  notifications  removed. 


Mark  all  project  data  as  viewed 

l.The  “normal  change  case”,  “Remove  Object”,  or  “Add  object”  scenario  has  occurred  and 
some  object  or  Field  is  being  displayed  as  “new”  or  “changed”  or  “deleted”. 

2. Step  one  may  have  occurred  multiple  times,  so  that  at  least  1  or  more  changes  are 
indicated  by  the  system  to  User-B. 

3.User-B  indicates  that  all  change  notifications  for  the  project  be  reset. 

4. System  sets  all  “newly  changed”  and  “new”  objects  as  “viewed”  for  User-B.  System 
removes  all  references  to  deleted  items  for  User-B. 


Viewing  and  closing  or  “touching”  marks  as  “viewed” 

1 .  The  “normal  change  case”,  “Remove  Objecf ’,  or  “Add  objecf  ’  scenario  has  occurred 
and  some  object  or  Field  is  being  displayed  as  “new”  or  “changed”  or  “deleted”. 

2.  User-B  Selects  to  view  data  that  is  marked  as  “New”,  “newly  changed”,  or  “deleted”. 

3.  If  the  data  is  marked  as  “new”  or  “newly  changed”,  it  becomes  marked  as  “viewed”  If 
the  indication  is  that  the  field  is  “deleted”,  then  the  indication  will  disappear  when 
unselected. 


Undo/Redo  scenarios 

It  has  been  determined  that  there  is  a  need  for  a  user  to  keep  their  own  redo/undo  stacks  in  place 
instead  of  only  keeping  track  of  this  data  via  one  huge  history  of  actions  that  can  be  reverted. 
First  off,  a  user  having  an  “undo”  button  that  could  undo  the  last  action  made  by  ANY  team 
member  seems  dangerous.  If  User-A  makes  a  change  that  they  wish  to  undo,  but  User-B  makes 
several  changes  after  User-A’ s  last  change,  then  User-A  could  potentially  and  mistakenly  undo 
all  changes  made  by  User-B!  There  is  still  a  need  for  a  collaborative  reverting  functionality  and 
also  to  hash  out  particulars  of  undo/redo  stacks  where  other  users  could  make  changes  and 
invalidate  the  undo/redo  stack. 

Undo/redo  information  is  captured  on  a  per  client  session  basis.  Other  potential  options  include  a 
per  view  basis,  providing  an  infinite  stack  of  undo/redo  maintained  by  the  server,  or  providing  a 
finite  number  of  undo/redo  actions  to  be  available. 

Undo  Action. 

User  has  made  a  change  that  he/she  wishes  to  undo.  The  user  will  only  want  to  undo  his 
changes  made  and  will  not  via  this  capability  have  the  ability  to  undo  someone  else’s 
changes.  In  this  scenario,  the  client  will  keep  track  of  all  of  the  user’s 
changes/additions/removals  in  an  undo  stack.  The  Client  will  determine  other  user’s  actions 
that  affect  data  on  this  stack  so  that  the  user  wishing  to  “undo”  will  have  the  ability  to 
determine  what  changes  should  be  kept. 
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1 .  User-A  has  made  a  change  or  performed  an  action  that  can  be  undone,  (see  Normal 
change  Scenario) 

2.  User-A  selects  to  undo  the  last  made  change. 

3.  System  will  retrieve  the  lock  for  User-A  for  the  field  or  fields  affected  by  the  action. 

4.  If  the  system  retrieves  the  lock  (see  normal  change  case  for  not  receiving  the  lock),  then 
all  users  currently  viewing  the  locked  field(s)  will  receive  an  indication  that  the  field  is 
locked. 

5.  System  will  determine  if  the  field  or  fields  have  been  modified  by  other  users. 

a.  (most  likely  case)The  Field(s)  have  not  been  modified  by  other  users. 

i.  The  system  performs  the  changes  to  the  field(s). 

ii.  The  system  saves  these  changes  back  to  the  project  history. 

iii.  All  users  currently  viewing  the  field  will  see  that  the  field  has  changed. 

iv.  The  change/action  is  moved  from  User-A’ s  undo  stack  to  the  redo  stack. 

b.  The  Field(s)  have  been  modified  by  other  users. 

i.  The  system  informs  User-A  that  another  user  has  modified  the  field. 

ii.  The  system  directs  user  to  the  change  history  in  order  to  utilize  the 
revert  functionality. 

iii.  The  change/action  is  removed  from  the  undo  stack. 

6.  The  system  releases  User-A’s  lock  on  the  field(s). 

7.  If  the  Undo  stack  is  empty,  the  system  will  remove  the  ability  to  undo  from  user- A 

8.  If  the  redo  capability  is  not  available  and  the  redo  stack  is  not  empty,  the  system  will 
provide  User-A  with  the  ability  to  redo. 

Redo  Action. 

1 .  User  A’s  last  action  was  to  undo  a  change  or  changes. 

2.  User  A  wishes  to  redo  an  action  that  was  undone. 

3.  System  will  retrieve  the  lock  for  User-A  for  the  field  or  fields  affected  by  the  action. 

4.  If  the  system  retrieves  the  lock  (see  normal  change  case  for  not  receiving  the  lock),  then 
all  users  currently  viewing  the  locked  field(s)  will  receive  an  indication  that  the  field  is 
locked. 

5.  System  will  determine  if  the  field  or  fields  have  been  modified  by  other  users. 

a.  The  field(s)  has  not  been  modified  by  other  users. 

i.  The  system  performs  the  changes  to  the  field(s). 

ii.  The  system  saves  these  changes  back  to  the  project  history. 

iii.  All  users  currently  viewing  the  field  will  see  that  the  field  has  changed. 

iv.  The  change/action  is  removed  from  User-A’s  redo  stack  is  now  added 
to  the  undo  stack. 

b.  The  Field(s)  have  been  modified  by  other  users. 

i.  The  system  informs  User-A  that  another  user  has  modified  the  field. 

ii.  The  system  directs  user  to  the  change  history  in  order  to  utilize  the 
revert  functionality. 

iii.  The  change/action  is  removed  from  the  redo  stack. 

6.  The  system  releases  User-A’s  lock  on  the  field(s). 

7.  If  the  redo  stack  is  empty,  the  system  will  remove  the  ability  to  redo  from  User-A 
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8.  System  will  determine  if  the  undo  staek  is  empty.  If  it  is  empty,  the  system  will  disable 
the  undo  eapability. 


Reverting  Collaborative  changes  Scenarios 

These  seenarios  involve  reverting  ehanges  potentially  made  by  one  or  more  users,  not  neeessarily 
made  by  the  User  performing  the  aetion  in  the  seenario. 

One  item  to  consider  would  be  how  far  back  change  history  data  is  captured.  There  is  a  potential 
for  a  lot  of  data  to  be  captured  if  we  are  dealing  with  keeping  track  of  every  object/attribute 
creation,  modification,  and  deletion  for  every  project.  To  handle  this  potential  problem,  we  need 
to  provide  an  administrator  the  ability  to  clear  the  change  history. 

Restore  a  Removed  Object 

Since  all  removed  objects  allow  for  a  visual  indication  that  the  object  has  been  removed,  it 
provides  a  “special-case”  scenario  where  the  removed  object  can  be  brought  back  via  the 
visual  cue  that  it  had  been  removed. 

1 .  User-A  receives  a  visual  indication  that  Element-A  has  been  removed. 

2.  User-A  indicates  that  Element-A  should  be  re-added  back  to  the  project. 

3.  The  system  restores  Element-A. 

4.  Element-A  will  appear  as  no  longer  deleted,  but  as  “modified”  by  all  other  users  who 
are  capable  of  viewing  it. 


View  Change  History/Revert  due  to  Change  History  for  a  field 

1 .  User-A  selects  a  field  and  indicates  to  view  change  history  of  that  field. 

2.  System  displays  a  list  of  changes,  organized  by  time  and  by  the  user  associated  with  the 
change 

3.  User-A  may  select  an  item  from  the  list  of  changes  or  close  the  display. 

a.  User-A  closes  the  display. 

i.  The  system  closes  the  display. 

b.  User-A  selects  an  item. 

i.  User-A  indicates  that  the  field  be  reverted  to  the  selected  item. 

ii.  The  system  locks  the  field  for  User-A.  (If  lock  is  not  attainable,  then  no 
action  will  take  place  -  user  will  be  notified) 

iii.  The  system  will  revert  the  changes  to  the  selected  item. 

iv.  The  system  releases  the  lock  for  the  field. 

V.  All  users  viewing  the  field  will  be  notified  of  the  modification. 

vi.  The  display  is  updated  to  now  include  the  new  change  by  User-A. 

vii.  User-A  repeats  step  3b. 

View  change  history/Revert  changes  due  to  Change  History  for 
selected  fields,  element,  element  type,  view,  or  project. 

Note:  “Element  type”  includes  allowing  the  user  to  view  changes  for  a  specific  type  of 
object.  For  example,  the  user  may  want  to  see  all  the  changes  made  to  Facts  or  to  CO  A  1 . 
An  element  is  anything  that  is  displayed  on  a  view  that  can  represent  different  types  of 
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information.  For  example,  seleeting  an  Operational  Objeetive  on  the  Sketeh  or 
Synchronization  view  is  selecting  all  fields  represented  by  that  00,  maybe  including  its 
children.  It  includes  multiple  fields/attributes,  maybe  even  multiple  objects.  This  also 
allows  for  viewing  deleted  items. 

1.  User-A  selects  one  of  the  following:  individual  fields,  an  element  representing  multiple 
fields  (an  object),  an  element  type,  indicates  a  view,  or  wishes  to  view  ALL  project  data 
changes. 

2.  The  system  determines  all  of  the  fields  involved  with  the  selected  fields,  element, 
element  type,  or  view.  If  viewing  all  project  changes,  the  system  will  display  a  view  of 
the  change  history  for  the  project,  ordered  by  timing,  also  displaying  the  name  of  the 
object,  the  field  changed,  the  user  responsible  for  the  change,  and  the  actual  change. 

3.  The  system  displays  a  list,  arranged  by  time  (default),  which  includes  the  name  of  the 
field,  the  change,  and  the  user  who  performed  the  change. 

4.  The  user  may  do  one  of  the  following: 

a.  User-A  changes  a  field: 

i.  User-A  selects  an  item  in  the  displayed  list  and  indicates  that  the  field  be 
reverted. 

ii.  The  system  locks  the  fields  required  to  revert  the  changes  requested.  (If 
lock  is  not  attainable,  then  no  action  will  take  place  -  user  will  be 
notified.  Also  see  scenario  0,  Request  a  lock) 

iii.  The  system  reverts  the  field  to  the  selected  change.  Users  viewing  the 
fields  will  have  visual  indication  that  the  field  has  updated. 

iv.  The  system  updates  the  displayed  list  to  include  the  latest  change  by 
User-A 

V.  Return  to  step  5  or  continue  to  step  6. 

b.  User-A  reverts  selected  data  to  a  specific  time: 

i.  User-A  selects  item  representing  the  last  change  made  that  he/she  wishes 
to  keep. 

ii.  User-A  indicates  to  revert  all  changes  in  time  made  after  the  selected 
item. 

iii.  The  system  locks  the  fields  required  to  revert  the  changes  requested.  (If 
lock  is  not  attainable,  then  no  action  will  take  place  -  user  will  be 
notified,  also  see  scenario  0,  Request  a  lock) 

iv.  The  system  complies.  The  users  viewing  the  fields  will  have  visual 
indication  that  the  field(s)  was  updated. 

V.  The  system  updates  the  displayed  list  to  include  the  latest  changes  by 
User-A.  The  system  releases  locks  on  this  data. 

vi.  Return  to  step  4  or  continue  to  step  5. 

5.  User-A  closes  the  display. 

User  filters  change  history  view. 

This  functionality  may  be  slated  for  future  spirals. 

In  order  to  provide  users  with  multiple  ways  to  search  through  change  history,  the  system 
will  allow  for  the  filtering  of  the  data  displayed  in  the  change  history  view  by  timing,  user 
responsible  for  the  change,  data  element,  element  type,  or  data  field  that  displayed  changes 
in  the  change  history  view. 


B-92 


Collaborative  Data-Level  Permissions 

This  functionality  may  be  slated  for  future  spirals. 

“Collaborative  Data-Level  Permissions”,  for  the  purpose  of  this  document,  has  a  purpose  of 
locking  and  hiding  specific  project  data  until  the  data  is  available  to  share  out  with  the  rest  of  the 
team  or  users  with  roles  allowing  access  to  the  project.  The  locking  will  be  expanded  to  include 
editing  (or  “write  access”)  to  specific  data  within  a  project  for  an  individual  or  group  of 
individuals.  The  system  will  also  provide  the  hide/show  (or  read-only  access)  to  users, 
designated  by  someone  who  has  write  access  to  that  data.  The  purpose  of  this  is  to  allow  work  to 
be  done  by  a  single  individual  or  by  a  team  of  users  collaboratively  without  sharing  unfinished 
work  to  others  who  are  working  outside  of  the  process. 

Snapshots 

This  functionality  may  be  slated  for  future  spirals. 

The  purpose  of  this  functionality  is  to  allow  the  user  to  take  a  picture,  or  “snapshof  ’  of  a  view  or 
group  of  views.  This  will  allow  users  to  capture  information  and  data  as  it  was,  before  it  was 
modified  and  before  the  view  was  changed.  Capturing  this  information  will  aid  users  in  briefing 
as  well  as  quickly  viewing  historical  data. 

Some  proposed  implementation  methods  of  this  include  something  as  simple  as  capturing  images 
of  the  views  to  the  more  complicated  capability  of  being  able  of  using  the  change  history  to 
revert  a  view  to  display  data  captured  at  a  time  in  the  past. 

Reviewing/Mitigation 

This  functionality  may  be  slated  for  future  spirals. 

Holding  off  until  further  clarifications  from  SMEs  on  what  the  requirements  are  elicited. 
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Workflow  Use  Cases 


Use  Case  5.1 :  Add  Workflow  Step 

User  Story  /  Context  of  Use: 

•  The  workflow  view  provides  a  list  of  steps  needed  to  complete  a  COA.  Each 
workflow  step  will  have  an  associated  checklist  of  actions  to  complete  and  a 
percentage  complete  (of  all  actions  items  for  the  workflow  step).  A  default  workflow 
will  appear  in  the  workflow  view. 

•  The  User  may  need  to  add  an  intermediate  step  to  the  workflow  to  increase  the  level 
of  detail  or  accuracy  in  the  workflow  to  facilitate  strategic  planning. 

•  The  user  may  add  checklist  items  to  the  workflow  step  see  Use  Case  5.4  Edit 
Checklist-  Add  action  item. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  project  is  open  in  COA  Sketch  and  Workflow  view  is  active. 

Triggers:  The  User  would  like  to  add  a  workflow  step. 

Guarantees: 

•  New  workflow  step  appears  with  correct  name,  position  and  %  complete. 

•  The  %  complete  will  default  to  0%. 

Main  Success  Scenario: 

1 .  The  user  indicates  that  they  would  like  to  add  a  workflow  step. 

2.  The  system  requests  workflow  step  information  (workflow  name,  location  and  % 
complete). 

3.  The  user  enters  the  new  workflow  step  information. 

4.  The  system  displays  the  newly  added  workflow  step. 

Alternative  1:  The  User  Cancels  add  workflow  step 

1 .  The  user  indicates  that  they  would  like  to  add  a  workflow  step. 

2.  The  system  requests  workflow  step  information  (workflow  name,  location  and  % 
complete). 

3.  The  user  indicates  that  they  would  like  to  cancel  this  action. 

4.  The  system  returns  to  the  workflow  view  and  it  is  unchanged. 

Requirements: 


Use  Case  5.2:  Remove  Workflow  Step 

User  Story  /  Context  of  Use: 

•  User  might  need  to  remove  a  step  from  the  workflow  because  it  is  no  longer  needed 
or  does  not  apply  to  the  current  COA. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
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Supporting  Actors:  CO  A  Sketch 
Preconditions: 

•  A  plan  is  open  in  COA  Sketch  and  Workflow  view  is  active. 

Triggers:  The  User  would  like  to  remove  workflow  step. 

Guarantees: 

•  Workflow  step  and  associated  check  list  is  removed. 

•  The  workflow  step  is  not  removed  if  user  does  not  confirm  the  action. 

Main  Success  Scenario: 

1 .  The  user  selects  a  workflow  step  and  indicates  they  would  like  to  remove  it. 

2.  The  system  prompts  for  confirmation  that  the  user  would  like  to  remove  the  workflow 
step  and  the  associated  checklist. 

3.  The  user  confirms. 

4.  The  system  removes  the  workflow  step. 

Alternative  1:  Cancel  Workflow  Remove. 

1 .  The  user  selects  a  workflow  step  and  indicates  they  would  like  to  remove  it. 

2.  The  system  prompts  for  confirmation  that  the  user  would  like  to  remove  the  workflow 
step  and  the  associated  checklist. 

3.  The  user  indicates  that  they  would  not  like  to  remove  the  workflow  step. 

4.  The  system  returns  to  the  Workflow  view  unchanged. 

Requirements: 


Use  Case  5.3:  Edit  Workflow  Step 

User  Story  /  Context  of  Use: 

•  User  may  need  to  edit  workflow  step  to  better  describe  the  workflow.  The  user  may 
change  the  name,  position  or  %  complete  of  the  workflow  step. 

•  The  system  will  calculate  a  %  complete  for  the  workflow  step  based  on  the 
completion  status  of  items  in  the  checklist,  however,  this  may  not  accurately  reflect 
the  user’s  perception  of  the  %  complete,  so  the  user  may  change  that  percentage 
manually. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  All  Users 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  A  plan  is  open  in  COA  Sketch  and  Workflow  view  is  active. 

Triggers:  The  User  would  like  to  change  an  attribute  of  the  workflow  step. 

Guarantees: 

•  The  name,  position  and/or  percentage  complete  of  the  workflow  step  is  correctly 
modified. 

•  The  name,  position  and/or  percentage  complete  of  the  workflow  step  is  unaltered  if 
the  user  decides  not  to  edit  Workflow  step. 

Main  Success  Scenario: 

1 .  The  user  indicates  that  they  would  like  to  edit  the  workflow  step. 

2.  The  system  requests  input  for  workflow  name,  position  and  percentage  complete. 
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3.  The  user  indieates  desired  changes  to  workflow  name,  position  and  percentage 
complete. 

4.  The  system  displays  the  workflow  step  with  the  correct  workflow  name,  position  and 
percentage  complete. 

Alternative  1:  Cancel  Edit  Workflow 

1 .  The  user  indicates  that  they  would  like  to  edit  the  workflow  step. 

2.  The  system  requests  input  on  workflow  name  and  position. 

3.  The  user  decides  to  keep  previous  settings  and  indicates  they  would  like  to  cancel 
action. 

4.  The  system  displays  the  workflow  step  as  it  was  previously. 

Requirements: 


Use  Case  5.4:  Edit  Checklist:  Add  Action  Item 

User  Story  /  Context  of  Use: 

•  Each  workflow  step  will  have  an  associated  checklist  with  specific  action  items.  The 
User  may  need  to  add  an  action  item  to  the  default  checklist,  to  better  reflect  the  COA 
creation  process. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  plan  is  open  in  COA  Sketch  and  Workflow  view  is  active. 

Triggers:  The  User  would  like  to  add  an  action  item  to  the  checklist  for  a  particular 
workflow  step. 

Guarantees: 

•  New  action  item  appears  for  selected  workflow  step  with  correct  name,  position, 
status  and  percentage  complete  and  a  comment  if  applicable. 

•  The  completion  state  of  an  action  item  may  be  one  of  the  following:  not  started, 
started,  complete  (waiting  approval),  (requires)  rework,  approved,  and  not  applicable. 

•  The  default  completion  state  will  be  not  started. 

•  The  default  percentage  complete  will  be  0%. 

•  New  action  item  is  not  added  if  request  is  cancelled. 

Main  Success  Scenario: 

1 .  The  user  indicates  that  they  would  like  to  add  an  action  item  to  the  checklist. 

2.  The  system  requests  the  name,  position,  status,  percentage  complete  and  comment  for 
the  action  item. 

3.  The  user  supplies  the  requested  information. 

4.  The  system  displays  the  checklist  with  the  new  action  item  on  the  checklist. 
Alternative  1:  Cancel  Add  Action  Item 

1 .  The  user  indicates  that  they  would  like  to  add  an  action  item  to  the  checklist. 

2.  The  system  requests  the  name,  position,  status,  percentage  complete  and  comment  of 
the  action  item. 
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3.  The  user  decides  not  to  add  new  action  item  and  indicates  they  would  like  to  cancel 
action. 

4.  The  system  displays  the  checklist  as  it  was  previously  displayed. 

Requirements: 


Use  Case  5.5:  Edit  Checklist:  Remove  Action  Item 

User  Story  /  Context  of  Use: 

•  User  may  want  to  remove  an  Action  Item  from  the  list  if  it  does  not  apply  to  the 
current  plan. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  plan  is  open  in  COA  Sketch  and  Workflow  view  is  active. 

Triggers:  The  User  would  like  to  remove  an  action  item  from  the  checklist. 

Guarantees: 

•  The  action  item  is  removed  from  the  checklist. 

Main  Success  Scenario: 

1 .  The  user  selects  an  action  item  and  indicates  that  they  would  like  to  remove  the 
selected  action  item  from  the  checklist. 

2.  The  system  asks  the  user  if  they  are  sure. 

3.  The  user  confirms. 

4.  The  system  removes  the  item  from  the  checklist  and  presents  checklist  without  the 
specified  action  item. 

Alternative  1:  User  Cancels  Remove  Item  from  Checklist 

1 .  The  user  selects  an  action  item  and  indicates  that  they  would  like  to  remove  the 
selected  action  item  from  the  checklist. 

2.  The  system  asks  the  user  if  they  are  sure. 

3.  The  user  does  not  confirm. 

4.  The  system  presents  checklist  as  it  was  previously. 

Requirements: 


Use  Case  5.6:  Edit  Checklist:  Edit  Action  Item 

User  Story  /  Context  of  Use: 

•  User  may  need  to  edit  checklist  action  item  to  better  describe  the  workflow.  The 
user  may  change  the  name,  position,  status,  percentage  complete  or  the  comment 
of  the  checklist  action  item. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 


B-97 


•  A  plan  is  open  in  COA  Sketch  and  Workflow  view  is  active. 

Triggers:  The  User  would  like  to  change  an  action  item  name  or  action  item  position  in  the 
checklist. 

Guarantees: 

•  Action  item  appears  for  selected  workflow  step  with  correct  name,  position, 
status,  percentage  complete  and  comments  of  the  checklist  action  item. 

Main  Success  Scenario: 

1 .  The  user  indicates  that  they  would  like  to  edit  an  action  item. 

2.  The  system  opens  the  action  item  for  editing. 

3.  The  user  changes  one  or  more  of  the  following:  name,  position,  status,  percentage 
complete  and  comments. 

4.  The  system  returns  to  the  checklist  and  the  desired  changes  are  reflected. 
Alternative  1:  Cancel  Edit  Action  Item 

1 .  The  user  indicates  that  they  would  like  to  edit  an  action  item. 

2.  The  system  opens  the  action  item  for  editing. 

3.  The  user  makes  changes  and  changes  their  mind,  cancels  action. 

4.  The  system  returns  to  the  checklist  and  the  checklist  is  unchanged. 

Requirements: 


Use  Case  5.7:  Change  Action  Item  Status 

User  Story  /  Context  of  Use: 

•  Strategy  planners  can  change  the  completion  status  for  an  action  item  at  any  time. 
They  can  choose  a  completion  state,  percent  complete  and  add  a  comment  as  to  the 
state  of  their  work. 

•  The  user  may  change  their  completion  state  of  an  action  item  to  one  of  the  following: 
The  completion  state  of  an  action  item  may  be  one  of  the  following:  not  started, 
started,  complete  (waiting  approval),  (requires)  rework,  approved,  and  not  applicable. 

•  When  an  Action  Items  is  marked  as  Complete,  the  work  done  needs  to  be  approved. 
When  the  work  is  reviewed,  the  reviewer  may  choose  to  accept  (approved)  or  reject 
(rework)  the  work . 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  plan  is  open  in  COA  Sketch  and  Workflow  view  is  active. 

Triggers:  The  User  would  like  to  change  the  status  of  an  action  item. 

Guarantees: 

•  The  user  may  change  their  completion  state  of  an  action  item  to  one  of  the  following: 
not  started,  started,  complete  (waiting  approval),  (requires)  rework,  approved,  and  not 
applicable. 

•  The  user  may  indicate  a  percent  completion. 
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•  If  no  percentage  complete  is  indicated  the  default  will  be  0%  for  not  started,  25%  for 
started,  90%  for  complete,  75%  for  rework,  100%  for  approved  and  not  applicable 
will  not  have  a  value  for  percentage  complete. 

•  The  user  may  add  a  comment  to  the  action  item. 

•  Only  users  with  privileges  can  accept  or  reject  a  step. 

Main  Success  Scenario: 

1 .  The  user  selects  an  action  item  and  indicates  that  they  would  like  to  change  the  status 
of  that  action  item. 

2.  The  system  presents  the  action  item  status. 

3.  The  user  makes  changes  to  the  action  item  status  (completion  state,  percent 
completion  and  comment)  and  confirms  actions. 

4.  The  system  returns  to  the  action  item  checklist  and  retains  new  settings. 

Alternative  1:  Cancel  Change  Action  Item  Status 

1 .  The  user  selects  an  action  item  and  indicates  that  they  would  like  to  change  the  status 
of  that  action  item. 

2.  The  system  presents  the  action  item  status. 

3.  The  user  makes  changes  to  the  action  item  status  (completion  state,  percent 
completion  and  comment)  and  indicates  that  they  would  not  like  to  keep  those 
changes. 

4.  The  system  returns  to  the  action  item  checklist  and  retains  original  settings. 

Requirements: 


Use  Case  5.8:  View  Checklist  Status  Breakdown 

User  Story  /  Context  of  Use: 

•  At  any  time,  a  superior  or  strategy  planner  may  want  to  know  what  the  status  is  of  the 
planning  process.  They  can  view  the  completion  status  of  the  checklist.  If  more 
information  is  desired,  the  Action  Item  can  be  expanded  to  show  each  action  item’s 
completion  status,  percentage  complete  and  comments. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  plan  is  open  in  COA  Sketch  and  Workflow  view  is  active. 

Triggers:  The  User  would  like  to  view  the  details  of  the  checklist. 

Guarantees:  The  system  will  present  the  completion  state,  percent  complete  and  any 
comments  of  all  action  items  in  the  checklist. 
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Main  Success  Scenario: 

1 .  The  user  requests  action  item  status  breakdown.  The  user  selects  the  checklist  that 
the  user  would  like  to  see  the  breakdown  of. 

2.  The  system  presents  all  of  the  action  items  with  their  completion  state,  percent 
complete  and  any  comments  associated  with  each  action  item. 

3.  The  user  indicates  they  have  completed  viewing. 

4.  The  system  returns  to  the  checklist. 

Alternative  1: 

Requirements: 
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Administrative  Use  Cases 


Use  Case  16.1:  User  logs  onto  system 

User  Story  /  Context  of  Use: 

•  In  order  to  assure  security,  the  team  members  require  each  individual  to  have  access 
depending  upon  their  role  within  the  COA  and  Allocation  process.  This  will  allow  COA 
Sketch  to  ensure  that  each  member  has  read  and  write  access  to  the  pieces  and  parts  of  the 
planning  process  in  which  they  are  involved. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 

Preconditions:  User  has  an  account  on  the  COA  Sketch  system 
Triggers:  The  user  needs  to  use  the  COA  Sketch  tool. 

Guarantees: 

•  With  the  correct  username  and  password,  user  will  be  able  to  log  onto  the  system. 

Main  Success  Scenario: 

1 .  User  opens  COA  Sketch  (in  Internet  Explorer). 

2.  The  system  displays  the  login  dialog. 

3.  The  User  enters  usemame/password  and  selects  the  log-in  button. 

4.  The  browser  submits  the  data  securely  to  the  system  which  will  check  the  credentials 
and  return  whether  the  user  can  get  access  to  the  system  or  not. 

5.  In  the  case  that  the  user  is  allowed  to  access  the  system,  the  browser  would  load  the 
COA  Sketch  default  view. 

Alternative  1: 

4.  The  browser  submits  the  data  securely  to  the  system  which  will  check  the  credentials 
and  return  whether  the  user  can  get  access  to  the  system  or  not. 

5.  In  the  case  that  the  user  isn’t  allowed  to  access  the  system,  the  browser  would  re-load 
the  log-in  screen,  assuming  that  the  user  entered  his  usemame/password  wrong. 
(Return  to  step  2) 

Requirements: 

•  COA  Sketch  shall  ensure  that  each  member  has  read  and  write  access  to  the  pieces 
and  parts  of  the  planning  process  in  which  they  are  involved. 

•  The  system  shall  allow  users  with  appropriate  privileges  to  logon  to  the  system 


Use  Case  16.2:  User  logs  off  from  the  system 

User  Story  /  Context  of  Use: 

•  In  order  to  assure  security,  the  team  members  need  to  be  able  to  log  off  when  their  work  is 
done. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
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Preconditions:  User  has  an  account  on  the  COA  Sketch  system 
Triggers:  The  user  wants  to  stop  using  the  COA  Sketch  tool. 

Guarantees: 

•  Any  user  that  is  logged  in  can  log  out. 

Main  Success  Scenario: 

1 .  User  selects  the  “Log  Out”  option  from  the  COA  Sketch  menu. 

2.  The  system  logs  the  user  off  and  displays  the  login-screen  so  that  another  user  can  log 
in. 

Alternative  1: 

1 .  User  clicks  the  “X”  (Windows)  close  box  in  the  upper  right-hand  corner  of  the 
window 

2.  User  reboots  from  start  menu 

3.  Task  manager 

4.  Control-alt-delete 

5.  Close  laptop 

6.  Lost  power 
Requirements: 

•  The  system  shall  allow  the  user  to  logoff  without  shutting  down  the  program. 

Use  Case  16.3:  Open  Administrative  View 

User  Story  /  Context  of  Use: 

•  The  Administrators  of  the  system  will  require  a  way  to  have  access  to  and  to  review 
different  user  accounts  and  administrative  tasks.  This  view  enables 
viewing/adding/editing/deleting  Users,  Locations  and  Internationalizations  with  their 
Icon-sets.  The  non-admin  users  can  only  access  the  Internationalizations  and  Icon-sets. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Level 
Primary  Actor:  Administrator 
Supporting  Actors:  COA  Sketch 
Preconditions:  COA  Sketch  is  open 

•  The  administrator  is  successfully  logged  in 

Triggers:  The  Administrator  would  like  to  view  the  summary  of  tasks  or  review  user  account 
information 

Guarantees: 

•  The  Administrator  will  have  access  to  all  the  administrative  tasks  by  viewing  this 
summary. 

•  The  Administrator  will  have  access  to  view  existing  user  account  information  by  viewing 
this  summary. 

Main  Success  Scenario: 

1.  The  Administrator  selects  to  open  the  Administrative  View  through  COA  Sketch. 

2.  The  system  displays  the  view,  allowing  the  Administrators  to  manage  locations. 
Internationalizations  or  Icons,  and  users. 

Alternative  1: 

Requirements: 

•  The  system  shall  provide  a  separate,  protected  view  for  administration  of  the  tool. 
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Use  Case  16.4:  Create  new  location 

User  Story  /  Context  of  Use: 

•  Administrators  need  to  be  able  to  create  locations  before  adding  new  users. 

•  The  location  is  needed  to  determine  the  default  set  of  icons  and  which 
internationalization  COA  Sketch  will  be  using. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Administrator 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  The  Administrative  View  is  open 

•  The  administrator  is  successfully  logged  in 

Triggers:  The  Administrator  needs  to  create  a  new  account  for  a  team  member  or  individual, 
or  assign  a  different  location  to  an  existing  user.  The  location  must  exist  before  it  can  be 
added  to  user  accounts. 

Guarantees: 

•  The  Administrator  will  be  able  to  create  new  locations. 

•  Following  information  needs  to  be  collected: 

1 .  Enter  Name  of  the  location 

2.  Enter  latitude/longitude  (or  choose  from  the  map  by  drawing  a  shape  on  the  map 
view) 

3.  Choose  Internationalization  (us-AF,  us-NAVY,  us- ARMY. . .)  from  a  list 

Main  Success  Scenario: 

1 .  The  Administrator  has  opened  the  Administrative  View  and  selected  to  create  a  new 
Location. 

2.  The  system  displays  the  “Create  new  Location  View”  and  allows  the  Administrator  to 
create  a  new  Location. 

Alternative  1: 

1 .  The  Administrator  has  opened  the  Administrative  View  and  chosen  to  create  a  new 
Location  based  on  an  existing  one. 

2.  The  system  displays  the  “Create  new  Location  View”  and  populates  it  with  data  from 
the  existing  Location. 

3.  The  Administrator  modifies  the  form  and  saves  the  Location  under  a  new  name. 

4.  The  system  verifies  that  the  name  is  not  in  use  and  stores  the  Location  under  the 
given  name. 

Alternative  2: 

1 .  The  Administrator  has  opened  the  Administrative  View  and  chosen  to  create  a  new 
Location  based  on  an  existing  one. 

2.  The  system  displays  the  “Create  new  Location  View”  and  populates  it  with  data  from 
the  existing  Location. 

3.  The  Administrator  modifies  the  form  and  saves  the  Location  under  a  new  name. 

4.  The  system  verification  fails  because  the  Location  with  that  name  exists  already,  and 
the  system  displays  the  error  message  to  the  Administrator. 

5.  The  Administrator  can  choose  to  discard  his  changes  or  save  the  Location  under  a 
new  name. 
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6.  System  repeats  step  4  and  tries  to  save  the  Location,  or  alerts  the  user  that  the  name 
already  exists. 

Alternative  3: 

1 .  The  Administrator  has  opened  the  Administrative  View  and  chosen  to  create  a  new 
Location  based  on  an  existing  one. 

2.  The  system  displays  the  “Create  new  Location  View”  and  populates  it  with  data  from 
the  existing  Location. 

3.  The  Administrator  modifies  the  form  and  saves  the  Location  under  a  new  name. 

4.  The  system  verification  fails  because  the  Location  with  that  Latitude/Longitude  exists 
already  (or  the  lat/long  is  within  close  proximity  to  an  existing  location),  and  the 
system  displays  the  error  message  to  the  Administrator. 

5.  The  Administrator  can  choose  to  discard  his  changes  or  modify  the  longitude/latitude 
information. 

6.  System  repeats  step  4  and  tries  to  save  the  Location,  or  alerts  the  user  that  the  name 
already  exists. 

Alternative  4: 

1 .  The  Administrator  has  opened  the  Administrative  View  and  chosen  to  create  a  new 
Location  based  on  an  existing  one. 

2.  The  system  displays  the  “Create  new  Location  View”  and  populates  it  with  data  from 
the  existing  Location. 

3.  The  Administrator  modifies  the  form  and  saves  the  Location  under  a  new  name. 

4.  The  system  verification  fails  because  the  Location  with  that  Latitude/Longitude  exists 
already  (or  the  lat/long  is  within  close  proximity  to  an  existing  location),  and  the 
system  displays  the  error  message  to  the  Administrator. 

5.  The  Administrator  can  choose  to  disregard  the  system  alert  and  save  the  location 
anyway,  even  though  the  coordinates  are  almost  identical. 

6.  System  stores  the  new  location  under  the  given  name,  or  prompts  user  for  a  new  name 
if  a  location  with  that  name  already  exists. 

Requirements: 

•  The  system  shall  provide  the  administrator  with  an  option  to  create  a  new 
location. 

Use  Case  16.5:  View/Modify/Delete  existing  iocation 

User  Story  /  Context  of  Use: 

•  Administrators  need  to  be  able  to  see  a  list  of  already  specified  locations  so  that  the 

locations  can  be  modified  or  deleted. 

•  Administrators  need  to  be  able  to  modify  an  existing  location  to  use  a  different 

internationalization  (wording  of  dialogs,  objects,  etc.)  and/or  a  different  set  of  icons. 

They  also  might  want  to  set  a  location  as  the  new  “defauh”  that  will  be  pre-selected  when 

creating  new  users. 

•  Administrators  might  need  to  delete  a  location  that  is  no  longer  useful. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Administrator 

Supporting  Actors:  COA  Sketch 

Preconditions: 
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•  COA  Sketch  is  open. 

•  The  Administrative  View  is  open 

•  The  administrator  is  successfully  logged  in. 

Triggers:  The  Administrator  wishes  to  view/modify/delete  existing  locations. 

Guarantees: 

•  The  Administrator  will  be  able  to  view/modify/delete  a  location. 

Main  Success  Scenario: 

1.  The  Administrator  has  opened  the  Administrative  View  and  selected  to  view  the 
existing  locations. 

2.  The  system  shows  the  “Display  Location  View”. 

Alternative  1: 

2.  The  Administrator  is  viewing  a  location  and  chooses  to  modify  it. 

3.  The  system  shows  the  “Edit  Location  View”  and  allows  the  Administrator  to  modify 
the  settings  and  save  the  changes. 

Alternative  2: 

2.  The  Administrator  is  viewing  a  Location  and  decides  to  delete  it. 

3.  The  system  will  display  a  confirmation  prompt  to  the  user. 

4.  The  Administrator  chooses  to  confirm  the  Location  deletion. 

5.  The  system  deletes  the  Location  and  returns  to  the  “Display  Locations  View” 

Alternative  3: 

2.  The  Administrator  is  viewing  a  Location  and  decides  to  delete  it. 

3.  The  system  will  display  a  confirmation  prompt  to  the  user. 

4.  The  Administrator  chooses  not  to  delete  the  location. 

5.  The  system  returns  to  the  “Display  Locations  View”  without  deleting  anything. 

Requirements: 

•  The  system  shall  allow  the  user  to  view,  modify,  or  delete  locations. 

Use  Case  16.6:  Create  new  user  account 

User  Story  /  Context  of  Use: 

•  Throughout  the  COA  and  Allocation  process,  new  individuals  with  specific  skills  may 
need  to  be  added  to  the  team.  Also,  some  members  of  the  staff  may  be  required  to 
oversee  or  review  what  is  going  on  throughout  the  planning  process  or  see  the  end 
products  (i.e.  The  COA  brief  or  the  Allocation  Plan).  The  Administrator  requires  the 
ability  to  set  up  roles  with  specific  privileges  when  authorizing  these  accounts.  These 
roles  guarantee  that  each  individual  would  have  the  access  they  are  required  to  have. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Administrator 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  The  Administrative  View  is  open 

•  The  administrator  is  successfully  logged  in 

Triggers:  The  Administrator  needs  to  create  a  new  account  for  a  team  member  or  individual 

Guarantees: 

•  The  Administrator  will  be  able  to  create  new  accounts  for  other  individuals. 
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•  The  Administrator  will  be  able  to  set  up  read  and  write  privileges  and  assign  roles  to  the 
individual. 

•  The  Administrator  will  be  able  to  set  up  default  location  and  internationalization  for  the 
individual. 

•  Following  information  needs  to  be  collected: 

1 .  Name 

2.  Username 

3.  Password 

4.  Password  Confirmation 

5.  Rank 

6.  Title/Job  Position 

7.  Email 

8.  Email  Confirmation 

9.  Phone 

10.  Command  Location  (see  the  Location  use  cases) 

1 1 .  Personal  Internationalization  (user  preference) 

12.  Personal  Icon-set 

13.  Role  (Admin,  User,  View  only?,  others?) 

Main  Success  Scenario: 

1 .  The  Administrator  chooses  to  create  a  new  User  Account  from  the  “User 
Management  View” 

2.  The  system  displays  a  blank  form  where  the  Administrator  can  enter  the  user  details. 

3.  The  Administrator  fills  in  the  form  and  saves  the  changes. 

4.  The  system  stores  the  information  and  allows  the  new  user  access  to  COA  Sketch 
based  on  the  Administrator  input. 

Alternative  1: 

2.  The  system  fails  to  display  the  blank  form. 

3.  System  defaults  to  the  Administrative  View 

Alternative  2: 

3.  The  administrator  does  not  have  all  of  the  required  information 

4.  Administrator  cancels  User  Management  View 

Alternative  3: 

4.  The  system  fails  to  store  the  information  from  the  form 

Requirements: 

•  The  system  shall  allow  the  administrator  to  add  new  users. 


Use  Case  16.7:  View/Modify/Delete  user  account 

User  Story  /  Context  of  Use: 

•  The  Administrator  will  need  to  have  a  way  to  modify  existing  account  information  about 
each  user.  This  will  allow  the  Administrator  the  ability  to  update  information  or  include 
information  that  was  missing  when  the  account  was  initially  created. 
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•  The  Administrator  might  want  to  deactivate  a  user  account  for  various  reasons,  while 
keeping  the  user’s  information. 

•  Users  of  the  system  are  expected  to  have  turnover  rates  in  employment  or  may  just  have  a 
change  in  duty  and  job  requirements.  Any  accounts  that  are  no  longer  active  or  the  user 
no  longer  requires  access  to  the  system  should  be  able  to  be  removed  easily  from  the 
system. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Administrator 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  The  Administrative  View  is  open 

•  The  administrator  is  successfully  logged  in 

Triggers:  The  Administrator  needs  to  view/edit/delete  an  account  for  a  team  member  or 
individual 

Guarantees: 

•  The  Administrator  will  be  able  to  view  user  accounts. 

•  The  Administrator  will  be  able  to  edit  read  and  write  privileges  and  assign  roles  to  the 
individual. 

•  The  Administrator  will  be  able  to  edit  the  default  location  and  internationalization  for  the 
individual. 

•  The  Administrator  will  be  able  to  delete  the  user  account. 

•  Administrator  will  successfully  delete  a  user  account  from  system. 

•  Individual  will  no  longer  have  access  to  the  system  through  the  deleted  account. 

•  The  Administrator  will  be  able  to  change  the  user  passwords. 

Main  Success  Scenario: 

1 .  The  Administrator  chooses  to  view  user  accounts. 

2.  The  system  shows  the  “User  Management  View” 

3.  The  Administrator  chooses  to  view  a  specific  user  account  or  a  group  of  users. 

4.  The  system  displays  the  information  based  on  the  Administrator’s  choice. 

Alternative  1: 

4.  The  Administrator  is  viewing  a  user  account  and  wishes  to  make  some  modifications. 

5.  The  system  displays  the  user  details  in  a  way  that  can  be  modified  and  saved. 

6.  The  Administrator  enters  the  desired  information  and  stores  the  changes. 

7.  The  system  saves  the  changes  and  displays  the  changed  user  information. 

Alternative  2: 

4.  The  Administrator  is  viewing  user  details  and  chooses  to  delete  the  user  account. 

5.  The  system  displays  a  confirmation  dialog. 

6.  The  Administrator  confirms  deleting  the  user. 

7.  The  system  deletes  the  user  account  and  displays  the  “User  Management  View” 

Alternative  3: 

4.  The  Administrator  is  viewing  user  details  and  chooses  to  delete  the  user  account. 

5.  The  system  displays  a  confirmation  dialog. 

6.  The  Administrator  chooses  to  abort  the  action. 

7.  The  system  remains  in  the  user  details  view  without  deleting  the  user  account. 
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Requirements: 

•  The  system  shall  allow  the  administrator  to  view  user  aecounts,  modify  user 
information,  or  delete  user  aceounts 


Use  Case  16.8:  Add  new  internationalization 

User  Story  /  Context  of  Use: 

•  Users  of  the  system  will  be  able  to  create  new  internationalization  settings  and  assign 
new  icon-sets. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  The  user  is  successfully  logged  in. 

Triggers:  User  is  viewing  his/her  account  preferences  and  decides  to  create  new 
internationalization  settings  and/or  icon-set. 

Guarantees: 

•  COA  Sketch  will  display  the  internationalization  editor  and  allow  the  user  to  save  the 
changes  as  a  new  set. 

•  The  access  rights  are  set  when  the  new  Internationalization  is  created: 

1 .  The  creator  might  not  want  to  have  editing  permission  after  creating  it. 

2.  Everyone  could  be  allowed  to  edit  the  internationalization. 

3.  Only  the  administrators  could  be  allowed  to  make  changes. 

4.  Only  specific  users  (usernames)  are  allowed  to  make  changes. 

Main  Success  Scenario: 

1 .  The  User  chooses  to  add  a  new  Internationalization  to  COA  Sketch. 

2.  The  system  displays  the  list  of  currently  available  Internationalizations  and  prompts 
the  user  to  select  to  either  create  a  “blank”  new  one  or  to  modify  an  existing  one  and 
store  it  as  a  new  version. 

3.  The  User  chooses  to  create  a  new  Internationalization. 

4.  The  system  loads  a  blank  form  for  the  Internationalization  and  allows  the  user  to  save 
the  content,  once  all  the  required  data  is  entered. 

Alternative  1: 

2.  The  system  displays  the  list  of  currently  available  Internationalizations  and  prompts 
the  user  to  select  to  either  create  a  “blank”  new  one  or  to  modify  an  existing  one  and 
store  it  as  a  new  version. 

3.  The  User  chooses  to  create  a  new  Internationalization  based  on  an  existing  one. 

4.  The  system  loads  the  selected  Internationalization  and  allows  the  user  to  make 
changes  and  store  it  as  a  new  Internationalization. 

Alternative  2: 

2.  The  system  displays  the  list  of  currently  available  Internationalizations  and  prompts 
the  user  to  select  to  either  create  a  “blank”  new  one  or  to  modify  an  existing  one  and 
store  it  as  a  new  version. 
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3.  The  User  chooses  to  abort  the  operation 

4.  The  system  reverts  to  the  previous  user  view. 

Requirements: 

•  The  system  shall  allow  any  user  to  add  a  new  Internationalization. 

Use  Case  16.9:  View/Modify/Delete  internationalization  details 

User  Story  /  Context  of  Use: 

•  Users  of  the  system  will  be  able  to  view/edit/delete  the  internationalization  settings 
and/or  their  current  icon-set. 

•  In  some  cases  the  internationalization  might  use  different  wording  (or  a  completely 
different  language)  and  the  Users  might  want  to  look  it  up  for  a  specific  term. 

•  Authorized  users  of  the  system  will  be  able  to  delete  obsolete  internationalization 
settings  and/or  icon-sets. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  The  user  is  logged  in. 

•  User  must  be  authorized  to  edit  the  internationalization 
Triggers:  User  decides  to  view  his/her  account  preferences. 

Guarantees: 

•  COA  Sketch  will  display  the  internationalization  editor  and  allow  the  user  to  save  the 
changes. 

•  If  users  are  depending  on  a  deleted  internationalization,  they  will  be  automatically 
using  the  default  internationalization. 

•  Default  internationalization  is  read-only  and  can  not  be  deleted. 

Main  Success  Scenario: 

1 .  The  User  chooses  to  view  the  Internationalization  details. 

2.  The  system  displays  the  list  of  various  Internationalizations  currently  available. 

3.  The  User  chooses  one  of  the  options. 

4.  The  system  displays  the  Internationalization  settings. 

Alternative  1: 

4.  The  user  is  viewing  a  list  of  Internationalization  settings  and  decides  to  modify  a 
setting. 

5.  The  User  chooses  to  edit  the  Internationalization  within  COA  Sketch. 

6.  The  system  displays  the  list  of  currently  available  Internationalizations  and  prompts 
the  user  to  select  the  Internationalization  for  editing. 

7.  The  User  chooses  one  of  the  available  Internationalizations. 

8.  The  system  loads  the  selected  Internationalization  and  allows  the  user  to  save  the 
content,  once  all  the  required  data  is  entered. 

Alternative  2: 

4.  The  User  is  viewing  a  list  of  Internationalizations  through  COA  Sketch  and  decides  to 
remove  one  of  the  displayed  items. 
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5.  The  system  verifies  that  the  Internationalization  is  no  longer  needed  and  that  the  user 
is  authorized  to  delete  it. 

6.  The  system  deletes  the  Internationalization  and  associated  icons. 

Alternative  3: 

4.  The  User  is  viewing  a  list  of  Internationalizations  through  COA  Sketch  and  decides  to 
remove  one  of  the  displayed  items. 

5.  The  system  verifies  that  the  Internationalization  is  no  longer  needed  and  that  the  user 
is  authorized  to  delete  it. 

6.  The  system  verifies  that  the  Internationalization  is  no  longer  needed  and  that  the  user 
is  authorized  to  delete  it. 

7.  The  system  displays  a  meaningful  error  message  with  details  why  the 
Internationalization  can  not  be  removed. 

Requirements: 

•  The  system  shall  allow  authorized  users  to  view,  modify,  or  delete 
Internationalizations  associated  with  their  own  preferences. 


Use  Case  16.10:  Change  User  Password 

User  Story  /  Context  of  Use: 

•  Users  of  the  system  will  be  able  to  change  their  own  password. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 
Primary  Actor:  All  Users 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  The  user  is  logged  in. 

Triggers:  User  decides  to  change  his/her  password. 

Guarantees: 

•  COA  Sketch  will  display  the  user  details  and  allow  entering  a  new  password  and 
password  confirmation. 

•  To  avoid  typos,  the  password  needs  to  be  entered  twice. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  change  his  password. 

2.  The  system  displays  the  user  details  in  a  fixed  view  and  the  two  password  fields  that 
the  user  can  edit. 

3.  The  user  edits  the  password  and  password  confirmation. 

4.  The  system  compares  the  two  passwords  and  if  they  are  identical,  it  changes  the 
user’s  password. 

Alternative  1: 

4.  The  system  compares  the  two  passwords  and  if  they  are  not  identical,  it  alerts  the 
user,  and  prompts  the  user  to  re-enter  the  passwords  (returns  to  step3) 

Requirements: 

•  The  system  shall  allow  the  authorized  users  to  change  their  own  passwords. 
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Scope 

Identiflcation 

This  document,  Course  of  Action  (CO  A)  Sketch  Software  Users  Manual  (SUM),  contains 
information  necessary  to  operate  the  COA  Sketch  software.  This  SUM  deseribes  how  campaign 
planners  and  analysts  ean  plan  and  assess  military  operations  using  the  COA  Sketeh  eapability 
modules. 

This  doeument  is  not  intended  to  replace  or  supersede  any  Government  Coneept  of  Operations 
(CONOPS)  or  other  guidelines  and  instructions.  This  document  outlines  one  possible  concept  of 
how  these  modules  ean  be  used  together  to  aecomplish  a  variety  of  tasks  typically  performed  by 
a  planning  staff  operating  at  the  operational  level  of  war. 

COA  Sketch  System  Overview 

The  Course  of  Aetion  (COA)  Sketeh  applieation  is  comprised  of  several  modules  or  views 
designed  to  aid  Information  Operations  (10)  planning  and  in  future  enhaneements,  assessment. 
These  modules  inelude  Sketch,  Synchronization,  Operations,  Activities  and  Aetions  (OAA) 
Status,  Lines  of  Effeet  (LOE),  PEL  Assessment,  and  Effeet  Status.  Eaeh  view  provides  a  specifie 
perspective  on  plan  data.  COA  Sketch  provides  the  user  the  flexibility  to  choose  appropriate 
views  and  lay  them  out  in  a  manner  which  best  supports  their  work. 

COA  Sketch  is  integrated  into  the  Information  Operations  Planning  Capability  -  Experiment 
(lOPC-X)  database  ontology  whieh  will  ultimately  allow  data  to  be  exchanged  freely  with  other 
lOPC-X  Capability  Modules  (CM).  See  Error!  Reference  source  not  found,  for  the 
deployment  architeeture. 
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Figure  C-  1.  Deployment  Overview 

COA  Sketch  is  being  developed  under  the  Strategy  Planning  Visualization  Tool  (SPVT)  contract 
for  the  Air  Force  Research  Laboratory  (AFRL)  Human  Effectiveness  Directorate  (RH).  Primary 
operational  and  technical  direction  for  this  task  is  provided  by  the  JFCOM  Engineering  Staff 
Section  (J7)  10  Joint  Management  Office  (JMO)  and  SPAWAR  Systems  Center,  San  Diego 
(SSC  SD). 

Document  Overview 

This  document  addresses  the  overall  COA  Sketch  user  interface  and  the  various  COA  Sketch 
modules. 

This  SUM  is  designed  to  instruct  users  how  to  use  the  COA  Sketch  software  from  a  day-to-day 
hands-on  perspective.  This  document  is  organized  as  follows: 

a.  Section  1 :  Scope  -  states  the  purpose  and  focus  of  this  SUM 

b.  Section  2:  Referenced  Documents  -  identifies  other  documents  that  are  referenced 
throughout  this  document 

c.  Section  3:  Software  Summary  -  provides  a  detailed  summary  of  the  modules  used  in 
COA  Sketch 


C-6 


d.  Section  4:  Access  to  the  Software  -  details  initial  steps  to  install  and  access  the  software 

e.  Section  5:  Processing  Reference  Guide  -  detailed  description  of  how  to  use  CO  A  Sketch 
f  Section  6:  Future  Enhancement  -  description  of  modules  and  capabilities  partially 

implemented  that  are  planned  work  to  finish  for  COA  Sketch. 

g.  Section  7:  Notes 

h.  Appendix  A:  Acronyms  and  Terms 
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Software  Summary 

This  section  identifies  the  specific  modules  that  comprise  COA  Sketch  and  describes  the 
individual  modules  at  a  high-level. 

COA  Sketch  Capability  Modules 

COA  Sketch  is  composed  of  the  following  modules: 

•  Workspace 

•  Synchronization 

•  Sketch 

•  Plan  Player 

Locking 

COA  Sketch  is  based  upon  being  a  collaborative  tool.  Some  goals  of  this  tool  are  to  allow 
collaboration  and  modification  of  mission  data  at  any  level,  without  applying  unwanted  rule  sets 
on  the  user.  This  functionality  will  hopefully  aid  the  current  planning  process  by  providing  more 
collaboration,  more  easily  accessible  and  real-time  data  as  it  is  being  analyzed  and  determined. 

Workspace 

The  COA  Sketch  Workspace  provides  a  desktop  where  the  operator  will  launch  various  modules. 
It  provides  a  complete  environment  for  interaction  with  the  windowing  system. 

Synchronization 

Synchronization  module  displays  the  relationships  between  multiple  organizations.  Courses  of 
Actions,  and  other  planning  elements.  Its  temporal  display  communicates  each  element’s  overall 
contribution  to  the  campaign. 

Sketch 

Sketch  module  provides  the  ability  to  develop  plans  using  true  geographic  information.  Users 
can  associate  areas  on  the  map  to  Mission  Analysis  and  Strategy  elements  to  give  more  depth  to 
their  operations. 

Plan  Player 

The  Plan  Player  provides  a  means  to  view  the  plan  as  it  goes  through  the  Synchronization  (Gantt 
chart)  View  and  the  Map  Sketch  View  as  the  timing  of  different  elements  come  into  and  out  of 
focus. 

Locking 

COA  Sketch  is  a  collaborative  tool.  A  goal  of  this  tool  is  to  allow  collaboration  and  modification 
of  mission  data  at  any  level,  without  applying  unwanted  rule  sets  on  the  user.  To  fulfill  this 
requirement,  COA  Sketch  has  provided  a  locking  mechanism  that  will  allow  the  users  to  lock 
individual  fields  of  elements  as  opposed  to  locking  multiple  pieces  of  data  and  associated  data  of 
the  element  being  modified.  By  providing  a  fine-grained  locking  system,  COA  Sketch  will  aid 
the  current  planning  process  by  providing  more  collaboration  and  more  easily  accessible  and 
real-time  data  as  it  is  being  analyzed  and  determined. 
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Software  Inventory 

This  paragraph  has  been  tailored  out. 

Software  Environment 

This  paragraph  identifies  the  hardware,  software,  manual  operations,  and  other  resources  needed 
for  a  user  to  run  the  software. 

•  Required  Software: 

•  The  COA  Sketch  modules  are  integrated  into  Information  Operations  Planning 
Capability  -  Experiment  (lOPC-X)  and  are  deployed  in  the  lOPC-X  Server.  Please 
refer  to  the  lOPC-X  Software  Center  Operator  Manual  (SCOM)  for  instructions 
describing  the  installation  of  the  lOPC-X  Server. 

•  The  COA  Sketch  client  has  been  verified  to  work  properly  solely  with  the  Internet 
Explorer  7  web  browser  (with  Flash  9  or  10  installed).  Avoid  problems  with  other 
untested  browsers  by  using  Internet  Explorer  7,  since  the  system  may  not  work 
properly  on  anything  else. 

•  Other  Facilities,  Equipment,  or  Resources  that  Must  Be  Present:  The  lOPC-X  Server 
must  be  installed  on  a  Windows  based  system.  COA  Sketch  requires  access  to  the  lOPC- 
X  Server,  which  includes  the  Oracle  Database  and  WebLogic  Application  Server. 
Specifics  on  the  required  resources  are  contained  in  the  lOPC-X  SCOM. 

Software  Organization  and  Overview  of  Approach 

COA  Sketch  consists  of  several  distinct  modules  accessed  via  a  single  Workspace.  These 
modules  are  described  individually  as  they  relate  to  various  processes  associated  with  campaign 
planning  and  execution. 

Contingencies  and  Alternate  States  and  Modes  of  Operation 

This  paragraph  has  been  tailored  out. 

Security  and  Privacy 

Users  may  not  make  unauthorized  copies  of  software  or  documents. 

Assistance  and  Problem  Reporting 

If  additional  assistance  is  required  after  reviewing  the  COA  Sketch  SUM,  contact  the  lOPC-X 
Program  Office. 

lOPC-X  Program  Office 

AFRL/RHCP 

2310  Eighth  Street,  Building  167 
Wright  Patterson  AFB,  OH  45433-7801 
Commercial:  (937)  255-8814 
DSN:  785 
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Access  to  Software 
Equipment  Familiarization 

This  paragraph  has  been  tailored  out. 

Access  Control 

Log  on  eredentials;  username  and  password  are  required  to  conneet  to  the  lOPC-X  server.  LFsers 
can  not  install  the  COA  Sketch  service  without  a  valid  account.  These  credentials  will  be 
provided  by  the  lOPC-X  Server  administrator.  The  administrator  will  not  only  add  users,  but 
delete  and  change  passwords  when  needed.  Please  see  the  installation  guide  for  further 
information  on  installing  COA  Sketch  and  using  the  lOPC-X  credentials. 

Other  than  the  control  of  the  network  in  which  COA  Sketch  service  is  installed,  there  is  no 
access  control  in  place  for  COA  Sketch.  Currently  a  user  can  log  on  to  COA  Sketch  with  a  user 
name.  The  usernames  are  not  controlled  and  are  user-defined.  There  is  currently  no  log  on 
password  required  to  use  COA  Sketch. 

The  COA  Sketch  client  is  accessible  through  a  Uniform  Resource  Locator  (URL)  determined  by 
your  host  location.  Access  to  COA  Sketch  and  associated  modules  are  controlled  via  the  host’s 
accessibility. 

Installation  and  Setup 

Detailed  installation  and  setup  information  of  COA  Sketch  is  addressed  in  COA  Sketch 
Installation  Guide. 

Detailed  installation  and  setup  information  of  the  lOPC-X  Server  is  addressed  in  the  lOPC-X 
SCOM. 

Navigate  to  the  Client 

COA  Sketch  is  a  thin  client  application.  The  client  is  compliant  with  Internet  Explorer  7  and 
requires  Adobe  Flash  Player  9  or  above. 

The  COA  Sketch  client  is  accessible  through  a  URL  determined  by  your  host  location. 

COA  Sketch  provides  both  Menu  and  Toolbar  access  to  tool  features  and  functionality.  The 
icons  used  in  both  locations  are  the  same.  Icons  in  the  toolbar  are  enabled  or  disabled  depending 
upon  support  by  the  currently  in-focus  (selected)  module.  See  Workspace  Section,  page  C-15,  for 
more  details. 
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COA  Sketch  Reference  Guide 


This  section  provides  the  user  with  procedures  for  using  the  COA  Sketch  software.  The  use  of 
the  modules  initiated  from  the  COA  Sketch  Workspace  is  described  in  detail  within  this  section, 

Conventions 

This  section  identifies  text  styles  or  diagram  features  that  have  special  meaning  in  Section  5  of 
this  document. 


annot 


A  balloon  is 
used  to 

annotate  items 


the  display. 


A  callout  is  used  to 


<directory  pathname>  Italicized  text  enclosed  by  angle  brackets  indicates  a  variable 

string.  Replace  the  entire  placeholder  (including  the  brackets  with 
the  appropriate  text. 


Locking 

Capabilities 

This  section  describes  the  Locking  feature  of  the  COA  Sketch  software.  The  use  of  locking 
within  COA  Sketch  is  to  prevent  users  from  trying  to  edit  the  same  element  at  the  same  time  and 
causing  the  server  to  only  accept  one  change.  Since  locking  is  controlled  at  a  finer  grained  level 
than  most  applications,  it  requires  some  introduction  as  to  what  the  different  locking  icons  and 
procedures  are  and  how  they  affect  the  user. 

This  locking  capability  allows  the  tool  to  save  information  immediately  for  all  users  to  see.  The 
data  is  saved  for  the  user  as  the  lock  is  released.  Because  of  this,  there  is  no  need  for  a  traditional 
‘save’  or  ‘publish’  capability  as  elements  are  saved  automatically  for  the  user. 

Processing  Procedures 
Getting  Started 

If  an  element  or  some  of  the  information  owned  by  that  element  (i.e.  a  ‘name’  or  ‘description’ 
field)  is  locked,  an  icon  appears  next  to  that  item. 

There  are  two  icons,  with  a  variation  of  each  icon. 

Solid  black  with  a  white  border  indicates  if  something  is  locked,  but  the  current  user  does  not 
own  the  lock. 

i 


Variation  of  this  lock  is  a  25%  transparency  and  this  indicates  some  field  associated  to  the 
element  (like  the  ‘name’  field)  is  locked  and  the  current  user  does  not  own  the  lock. 
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fi 


Solid  black  with  a  white  border  and  a  white  clock  on  it  indicates  if  something  is  locked  and  the 
current  user  owns  the  lock. 

6 

Variation  of  this  lock  is  a  25%  transparency  and  this  indicates  some  field  associated  to  the 
element  (like  the  ‘name’  field)  is  locked  and  the  current  user  owns  the  lock. 

3 


Locks  are  released  within  a  form  or  window  when  the  focus  moves  from  the  locked  field.  This 
can  be  accomplished  by  moving  to  a  different  field  or  selecting  a  different  item.  The  user  may 
also  select  a  different  module  within  the  system.  In  most  cases,  a  lock  must  be  released  before 
the  user’s  modifications  are  saved. 


Lock  Alerts 

The  system  allows  a  user  to  keep  the  lock  on  a  field  for  15  minutes.  After  the  15  minutes  if  no 
action  is  made  the  lock  is  released  and  a  new  user  can  lock  the  item  for  edits.  The  user  will  get  an 
alert  message  after  10  minutes  letting  them  know  the  lock  will  expire  in  5  minutes.  The  user 
must  renew  the  lock  or  release  the  lock  before  the  lock  expires  or  no  changes  will  be  saved. 

Note:  The  locking  timeout  can  be  configured  through  lOPC-X. 


Figure  C-  2.  Lock  Alerts 

The  alert  message  contains  the  following  data: 

•  The  name  of  the  field  that  is  locked 

•  The  time  the  alert  was  sent  to  the  user 

•  The  time  the  lock  will  expire  on  the  field 
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A  button  allowing  the  user  to  renew  the  lock 
A  button  allowing  the  user  to  dismiss  the  lock  alert 


The  Dialog  message  allows  for  a  “Renew  All”  locks  or  “Clear  All”  alerts  capability. 

Setting  Preferences 

The  user  can  set  certain  preferences  on  how  the  Locking  Alerts  are  displayed.  To  set  these 
preferences,  select  Preferences. . .  under  the  View  menu.  Next,  click  on  the  Lock  Alerts  icon. 


Figure  C-  3.  Lock  Alerts  Preferences 

There  are  three  choices  for  displaying  the  locking  alerts. 

•  Alert  Dialog  -displays  an  Alert  dialog  box. 

•  Alert  Balloon  (Default)  -  displays  a  Balloon  for  a  few  seconds  in  the  bottom  right  hand 
comer  of  the  screen. 

•  Both  -  utilizes  both  the  Dialog  box  and  Balloon  messaging. 

Lock  Alert  Preferences  are  associated  with  the  username  entered  upon  login. 

Workspace 

Capabilities 

The  COA  Sketch  W  orkspace  provides  a  deskto  p  environment  for  the  modules.  It  g  ives  the  user 
the  feel  of  a  desktop  application  with  the  convenience  of  a  thin  cl  lent  web  application.  It  is  the 
central  loc  ation  to  aid  Inf  ormation  Operation  s  (10)  planning  and,  in  future  enhancem  ents, 
assessment  for  campaign  planners  and  analysts. 

Processing  Procedures 

The  Workspace  allows  the  user  to  create  and  manage  operations.  From  within  the  Workspace,  a 
user  can  view  an  operation  in  any  combination  of  open  modules.  It  also  provides  convenient 
windowing  functions  like  minimize  all,  cascade,  and  tile. 
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Getting  Started 

The  COA  Sketch  Workspace  is  accessible  through  a  URL  determined  by  your  host  location.  See 
an  lOPC-X  System  Administrator  for  more  details.  Once  the  COA  Sketch  Client  URL  has  been 
loaded,  and  has  entered  the  correct  log  on  information  a  user  can  open  an  existing  operation, 
create  new  operations,  and  view  or  manipulate  the  operation  in  any  combination  of  COA  Sketch 
modules. 


Logging  in  to  COA  Sketch 

Once  the  COA  Sketch  Client  URL  has  been  loaded  the  user  will  be  prompted  to  enter  a  user 
name.  User  names  may  be  any  set  of  characters  and  are  case-sensitive.  If  logging  on  for  the  first 
time,  the  user  may  choose  his/her  own  username  and  type  it  in.  The  user  designates  him  or  her  in 
the  system  by  this  username.  The  username  is  used  by  the  system  to  track  locking,  preferences, 
as  well  as  creation,  deletion,  and  modification.  Once  logged  on  a  user  can  open  an  existing 
operation  or  create  new  operations. 


COA  Sketch  Login 
Username: 


Login 

I - 1  Enter  user  name  I - ^ - 

for  COA  Sketch 

Figure  C-  4.  COA  Sketch  Log  On 

Note:  There  are  no  controls  in  place  to  ensure  that  a  user  has  only  one  username,  nor  are  there 
controls  to  ensure  that  a  username  is  unique  and  not  shared  among  different  users.  If  a  username 
is  misspelled  or  uses  different  capitalization,  a  new  user  name  will  be  created  for  the  misspelled 
or  incorrectly  capitalized  name. 


Creating  a  New  Operation 

There  are  several  ways  to  create  a  new  operation: 

•  File  menu 

•  Toolbar 

•  Operation  Manager 

File  menu:  Under  the  File  menu,  select  New  Operation. ...  See  Error!  Reference  source  not 
found..  A  prompt  will  appear  to  name  the  new  operation.  Enter  a  name  and  click  OK.  The  new 
operation  will  be  opened  automatically  in  the  modules  currently  active  in  the  Workspace  and  the 
Operation  Editor  will  be  displayed.  See  page  C-22  for  details  on  setting  up  the  operation  for  use. 
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File  Edit  View 

New 

Operation 

^  Oper>  Operation  Manager.,* 

i 

Exit 

Figure  C-  5.  New  Operation...  File  menu 

Toolbar:  Similarly,  click  the  New  Operation  button  on  the  Workspace  Toolbar.  See  Figure  C-6. 


New  1 

File  Edit  View 

Operation 

Figure  C-  6.  New  Operation...  Toolbar 


Operation  Manager:  Under  the  File  menu,  select  Open  Operation  Manager.  From  the  Operation 
Manager  you  can  also  create  a  new  operation  by  clicking  the  plus  sign  near  the  top  of  the 
manager.  See  Figure  C-7. _  . 


!ij0  Operation  Manager 

- ^ 

New 

[  a  j  [  j  L  %  J 

Operation  *  M  Jt  1  1  1 

1 

Name  a 

Archived 

Sample  Operation  | _ | 

1 

1^1  Display  Archived  Operations 

^  Open  j  ^  Done  j 1 

Figure  C-  7.  New  Operation...  Operation  Manager 

A  prompt  will  appear  for  you  to  name  the  new  operation.  Enter  a  name  and  click  OK.  The 
Operation  Manager  does  not  automatically  open  the  newly  created  operation;  see  page  C-16  for 
further  details  on  opening  an  operation. 

Managing  Operations 

The  Operation  Manager  allows  the  user  to  create,  rename,  delete,  archive,  and  open  operations. 
There  are  several  ways  to  open  the  Operation  Manager: 

•  File  menu 


C-16 


•  Toolbar 


Under  the  File  menu,  select  Open  Operation  Manager. . . 


Figure  C-  8.  Open  Operation  Manager...  File  menu 


Open  1 

File 

Edit 

View  - 

Operation 

IJ 

n 

Figure  C-  9.  Open  Operation  Manager...  Toolbar 


To  create  a  new  operation  in  the  manager,  See  page  C-16. 

Renaming  or  Deleting  an  Operation 

To  rename  or  delete  an  operation,  select  the  operation  in  the  table  and  click  the  appropriate 
button.  See  Figure  C- 10. When  an  operation  is  deleted  it  will  be 
removed  from  the  table  and  can  no  longer  be  opened. 

Operation  Manager 


Figure  C-  10.  Rename/Delete  Operation 
Import/Export  Operations 

In  the  Operation  Manager,  a  user  can  export  an  existing  Operation  to  a  fde  and  can  import  an 
exported  Operation  or  an  IWPC  4.2  plan  from  file. 
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Figure  C-  11.  Import/Export  Operations 


Archiving  an  Operation 


In  the  Operation  Manager,  a  user  can  filter  the  list  of  displayed  operations  by  choosing  to  hide 
operations  that  have  been  archived.  See  Figure  C-12.  for  details.  Currently,  the  archiving  operations 
feature’s  only  effect  is  if  it  is  displayed  in  the  list.  No  changes  to  the  operation  or  how  it  is  stored 
are  made. 


Operation  Manager 

l^j 


Display  Archived  Operations 


Open  j  ^  Done  j 

Figure  C-  12.  Archive  Operations 


Opening  an  Operation 

To  open  an  operation  into  the  Workspace,  select  the  operation  in  the  table  and  either  double  click 
the  operation  or  click  the  Open  button.  The  Operation  Manager  will  automatically  close  and  the 
selected  operation  will  be  open  in  the  modules  currently  active  in  the  Workspace.  Only  one 
operation  may  be  opened  within  a  single  instance  of  COA  Sketch.  If  another  operation  was  open, 
it  will  be  closed  before  the  selected  operation  is  opened. 
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Opening  a  Module 

From  within  the  Workspace,  there  are  several  modules  available  to  aid  in  10  planning  and 
assessment.  It  is  expected  that  different  modules  will  be  needed  at  different  stages  in  the 
operation.  To  view  a  module,  select  it  from  the  Module  menu.  The  Workspace  menus  and 
toolbars  adjust  to  contain  the  active  module’s  items. 

The  Synchronization  and  Sketch  modules  are  the  fully  implemented  modules  for  this  version  of 
COA  Sketch.  All  other  modules  listed  are  only  partially  implemented  and  planned  work  for 
future  versions  of  the  tool. 

Note:  The  file  menu  updates  as  different  modules  are  made  active.  The  desired  module  view 
must  be  selected  as  the  active  module  in  order  to  see  the  module’s  menu. 

File  Edit  View  Module  Window  Hi 


Synchronization 


^  Sketch 

M  OAA  Status  Matrix 
^  Lines  Of  Effect 
1^  PEL  Assessment 
V,  lO  Assessment 
Workflow 


Figure  C-  13.  Module  Meuu 

Once  a  module  is  selected,  a  window  will  open  containing  that  module’s  view.  The  module  will 
become  the  active  module  and  be  displayed  on  top  of  all  other  modules  open.  It  will  also  be 
displayed  as  a  module  available  in  the  status  bar  at  the  bottom  of  the  COA  Sketch  desktop. 
Working  in  the  Windowing  System 

Working  iu  the  Windowing  System 

Organizing  Open  Windows 

Under  the  Window  menu,  there  are  several  functions  available  to  aid  in  organizing  and  accessing 
open  modules  and  editors. 

Cascade  Windows  stacks  the  windows  on  top  of  one  another  with  each  Title  bar  visible  for 
selection  by  the  user. 

Tile  Windows  Horizontally  lays  out  the  windows  to  maximize  the  horizontal  space  available  for 
each  window. 

Tile  Windows  Vertically  lays  out  the  windows  to  maximize  the  vertical  space  available  for  each 
window. 

Minimize  All  shrinks  all  the  open  windows  down  onto  the  Module  Bar  at  the  bottom  of  the 


Workspace. 


C-19 


Restore  All  brings  all  the  open  windows  from  the  Module  Bar  at  the  bottom  of  the  Workspaee 
back  to  their  previous  size  and  position. 

Using  the  Task  Bar 

The  Task  Bar  is  located  at  the  bottom  of  the  windowing  system  and  will  appear  above  the  Plan 
Player  if  the  plan  player  is  not  hidden.  The  Task  Bar  will  have  a  button  available  for  every  open 
Module  and  Editor.  Clicking  on  the  button  will  bring  the  Module  or  Editor  in  focus  and  in  front 


Figure  C-  14.  Task  Bar 


Setting  Preferences 

The  user  can  set  certain  preferences  on  how  the  windowing  system  operates.  To  set  these 
preferences,  select  Preferences. . .  under  the  View  menu.  Next,  click  on  the  Desktop  icon.  See 

Figure  C-15. 
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Figure  C-  15.  Desktop  Preferences 
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Synchronization  Modnle 
Capabilities 

Synchronization  module  displays  the  relationships  between  multiple  organizations,  courses  of 
actions,  and  other  planning  elements.  Its  temporal  display  communicates  each  element’s  overall 
contribution  to  the  campaign. 

Processing  Procednres 

The  Synchronization  view  displays  text  for  mission  analysis  and  plan  artifacts  in  the  left  hand 
tree  pane  and  in  the  right  hand  Gantt  chart  pane.  Each  element  in  the  Gantt  pane  has  the 
following  attributes:  timing,  dependencies,  constraints,  and  properties. 

Getting  Started 

Setting  up  the  Operation 

In  order  to  add  items  to  the  Synchronization  module,  the  operation  must  be  configured  properly. 
When  you  create  a  new  operation  from  the  File  menu  or  the  toolbar  button,  the  Operation  editor 
is  automatically  displayed. 

To  manually  display  the  Operation  editor,  select  the  Operation  name  in  the  tree  pane  of  the 
Synchronization  view  and  click  the  Edit  Element  button  on  the  Synchronization  toolbar.  You 
may  also  right  click  on  the  Operation’s  name  and  choose  “edit”  from  the  drop  down  menu. 


Figure  C-  16.  Edit  Operation 


Note:  When  you  add  a  new  Operation,  default  alpha  days  are  also  created. 

•  D-day  will  have  an  unspecified  date  and  be  the  default  for  the  Operation.  The  default  day 
will  be  the  automatic  date  referenced  when  new  timing  (phases  or  scheduled  timing)  gets 
created 

•  C-day  will  reference  d-day  with  an  offset  of  0. 

•  M-Day  will  reference  d-day  with  an  offset  of  0. 

Alpha  days  can  be  updated  in  the  Operation  editor.  See  Section  0  for  details  on  opening  an 
element’s  editor. 
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On  the  Organizations  tab  of  the  Operation  editor,  eliek  the  plus  button  to  add  a  new  organization. 
With  the  organization  highlighted,  next  click  the  Edit  Organization  button  so  that  you  can  add  a 
Planning  Template  in  the  Organization  editor.  See  the  following  Figure  C-17. 
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Figure  C-  17.  Adding  an  Organization  with  a  Planning  Template 

You  can  adjust  any  of  the  organization  properties  like  Name,  Description,  or  Level  of  War  from 
the  Organization  editor  as  well.  Add  as  many  organizations  as  necessary. 


Note:  The  operation  must  have  at  least  one  organization  with  a  Planning  Template  to  begin 
planning. 


Now  the  Operation  should  have  at  least  one  organization  displayed  with  a  Planning  Template  in 
the  Synchronization  view  as  shown  in  Error!  Reference  source  not  found.. 
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Figure  C-  18.  Operation  with  Organization  and  Planning  Template 
Creating  a  New  Course  of  Action 

Select  the  Organization  name  in  the  tree  pane  and  click  the  New  Element  button  on  the 
Synchronization  toolbar.  See  Section  0  for  more  details  on  adding  new  elements  to  the  operation. 
Select  Course  of  Action  in  the  New  Element  dialog  and  click  OK.  A  COA  should  now  appear 
under  the  organization.  You  can  edit  the  COA  as  described  in  Section  0. 

Adding  Elements  to  the  Operation 

The  same  steps  are  followed  to  add  all  categories  of  COA  Sketch  elements  to  the 
Synchronization  module  (and  therefore  the  operation).  Highlight  the  category  or  the  parent 
element  you  wish  to  add  a  new  COA  Sketch  element  to.  You  can  add  the  element  by  either: 

•  Synchronization  menu 

•  Synchronization  toolbar 

•  Right  click  menu 


After  selecting  one  of  the  methods  above,  a  New  Element  dialog  (see  Figure  C-  20.  New  Element 
Dialog  Box )  will  appear  with  a  list  of  elements  that  can  be  added  to  the  selected  category  or  as  a 
child  to  the  selected  existing  element.  Select  the  desired  element  and  click  OK.  The  new 
planning  element  will  appear  in  the  Synchronization  tree  pane. 
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New  Element 
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Figure  C-  20.  New  Element  Dialog  Box 

After  selecting  ‘OK’,  the  dialog  box  will  disappear  and  the  Synchronization  module  will  be 
updated  to  show  the  new  element.  The  editor  for  the  element  selected  to  be  created  will  open  for 
further  modification  unless  the  “Skip  Configuration”  box  is  checked.  This  checkbox  is  stored  as 
a  user  preference  and  will  remain  in  whatever  state  the  user  leaves  it  in. 

Editing  Elements 

After  a  planning  element  has  been  added,  the  user  may  wish  to  update  the  properties  of  the 
element.  The  same  steps  are  followed  to  edit  all  categories  of  planning  elements  in  the  operation. 
Highlight  the  planning  element  you  wish  to  add  edit.  You  can  open  the  element  editor  by  either: 

•  Synchronization  menu 

•  Synchronization  toolbar 

•  Right  click  menu 


Each  type  of  element  has  a  unique  editor  based  on  the  properties  associated  with  it. 


Locate  In  Sketch  Module 

The  user  may  quickly  locate  the  shape(s)  associated  with  a  COA  Sketch  element  from  within  the 
Synchronization  module  by  selecting  the  element  listed  in  the  Synchronization  module  and  then 
clicking  the  icon  in  the  toolbar  as  shown  in  Figure  C-  21.  Locate  in  Sketch  Module. 
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Figure  C-  21.  Locate  in  Sketch  Module 


Adding  a  Timing  Element 

In  order  to  see  a  timing  element  in  the  Gantt  chart  of  the  Synchronization  module,  a  scheduled 
timing  must  be  added  to  the  element’s  editor  on  the  Timing  tab  or  by  the  right  click  menu  shown 
in 

Figure  C-  22Element  right  Click  Menu.  See  page  C-22  for  details  on  opening  the  element’s  editor. 
The  initial  timing  element  starts  at  the  default  date,  which  is  available  in  the  Operation  editor, 
and  ends  24  hours  later.  When  the  timing  element  is  selected  in  the  list  at  the  top  of  the  Timing 
tab,  you  can  edit  the  date  information  in  the  form  below.  You  can  also  set  this  information 
directly  in  the  Gantt  chart.  See  page  C-28  for  more  details  on  adjusting  elements  directly  in  the 
view. 
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Figure  C-  22.  Element  right  Click  Menu 


Setting  COA  as  Selected  Plan 

To  set  a  COA  as  the  selected  plan,  open  the  COA’s  editor  (See  page  C-25  for  details  on  opening 
the  element’s  editor.)  On  the  General  tab,  check  the  checkbox  at  the  bottom  of  the  tab  to  Mark  as 
Selected  Plan.  The  icon  for  the  COA  updates  in  the  tree  pane  to  show  it  is  the  selected  plan. 
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Figure  C-  23.  Selected  Plan 

Only  one  COA  per  organization  can  be  marked  as  the  selected  plan.  If  you  mark  a  second  COA 
as  the  selected  plan  in  an  organization,  the  first  will  become  unmarked  so  that  the  second  one  is 
now  the  one  selected  plan.  You  can  unselect  a  COA  as  the  plan  by  un-checking  the  checkbox  on 
the  General  tab  of  the  COA  editor  as  well. 


Deleting  Elements 

After  planning  elements  have  been  added,  the  user  may  wish  to  delete  an  element.  The  same 
steps  are  followed  to  delete  all  categories  of  planning  elements  in  the  operation.  Select  the 
planning  element  from  within  the  Synchronization  view  you  wish  to  permanently  delete  from  the 
operation.  You  can  delete  the  element  by  either: 

•  Synchronization  menu 

•  Synchronization  toolbar 

•  Right  click  menu 

Note:  By  Ctrl-Clicking  you  can  select  multiple  elements  to  be  deleted  at  one  time. 
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Figure  C-  24.  Delete  Element  Variations 

The  user  will  be  prompted  to  eonfirm  the  deletion.  Onee  a  planning  element  has  been  deleted 
from  the  Synehronization  module,  it  is  deleted  from  the  operation.  It  ean  never  be  retrieved.  If 
the  element  had  a  shape  assoeiated  with  it  on  the  Sketch  module,  the  shape  will  be  deleted  as 
well. 


Warning:  Deleting  a  parent  element  also  deletes  all  of  its  children. 

Adjusting  Elements  in  the  View 

Certain  properties  of  the  planning  elements  can  also  be  adjusted  directly  in  the  Synchronization 
module  without  opening  its  editor. 


Adjusting  the  Scheduled  Timing 

After  a  scheduled  timing  has  been  added  in  the  element’s  editor  (See  Section  0)  the  timing 
element  can  be  updated  in  the  Gantt  chart.  This  is  done  by  dragging  the  edges  of  the  element  to 
the  desired  location.  See  Eigure  C-25. 

•  Dragging  the  entire  element  shifts  it  on  the  timeline 

•  Dragging  the  inner  points  reset  the  Start  Date  or  Stop  Date 


Figure  C-  25.  Scheduled  Timing  Dates 


Timing  can  be  adjusted  by  splitting  the  timing  event  or  merging  it  with  another  timing  event.  To 
split  a  timing  element  right  click  on  the  element  and  select  split.  To  merge  elements  Ctrl  click 
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the  elements  you  want  to  merge  and  right  cliek,  seleet  merge.  See  Figure  C-26. 


Note:  Merging  will  merge  all  seheduled  timings  between  the  earliest  and  latest  element  clicked. 
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Figure  C-  26.  Split  and  Merge  timing 
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Adding  and  Adjusting  Phases 

Phases  can  be  added  by  opening  the  COA  editor  and  clicking  on  the  phase  tab,  (see  page  26  for 
information  on  opening  an  editor).  Phases  may  also  be  added  by  selecting  a  COA  in  the 
synchronization  module  and  right  clicking.  Choose  ‘Add  Phase”  from  the  right  click  menu. 
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Figure  C-  27.  Phase  Tab 
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Timing  on  phases  can  be  adjusted  by  clicking  on  the  Timing  Tab  within  the  Phase  tab.  The 
default  timing  of  a  phase  is  30  days.  The  first  phase  will  begin  on  the  Default  Date.  Follow  on 
phases  will  begin  immediately  after  the  last  phase. 


.ction 

.  nx 

klidation 

Figure  C-  28.  Timing  Tab 

After  phases  have  been  added  in  the  COA’s  editor  Phases  tab,  (See  page  C-25  for  information  on 
opening  an  editor)  the  phase  elements  can  be  updated  in  the  Gantt  chart.  This  is  done  by 
dragging  the  edges  of  the  element  to  the  desired  location.  When  the  Phases  are  selected,  square 
icons  are  displayed  and  are  used  via  the  drag  and  drop  method.  The  top  square  will  adjust  the  end 
date  of  the  Phase  to  the  left  of  the  icon.  The  bottom  square  will  adjust  the  start  date  of  the  Phase 
to  the  right  of  the  square  icon. 

□  Phase  0  Phase  I  p - ^  Phase  II 

Figure  C-  29.  Phase  bar  in  Gantt  chart 

Note:  Phases  are  in  whole  day  increments,  so  the  view  will  automatically  round  to  the  nearest 
whole  day. 
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Dragging  Elements  in  the  Tree  Pane 

After  planning  elements  have  been  added  to  the  operation,  you  can  move  them  in  the  tree  pane  to 
create  a  new  hierarchy  of  elements.  Drag  and  drop  the  element  to  the  desired  location  in  the  tree 
pane. 

Note:  If  the  CTRL  key  is  held  down  while  dragging  a  reference  will  be  made  to  the  object  and 
the  object  will  not  be  moved. 


Setting  Time  Zone 

The  user  may  wish  to  switch  to  a  different  time  zone.  The  time  zone  can  be  set  in  two  ways: 

•  Synchronization  menu  selection. 

•  Synchronization  Toolbar  dropdown 


The  currently  selected  Time  Zone  shows  a  dot  next  to  it  in  the  menu  and  is  displayed  in  the 
dropdown  in  the  Synchronization  toolbar.  See  Error!  Reference  source  not  found.O  for  more 
details. 
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Figure  C-  30.  Time  Zone 

Available  time  zones  were  registered  when  COA  Sketch  was  installed.  See  COA  Sketch 
Installation  Guide  for  details. 

Note:  Time  zone  cannot  be  set  unless  a  specified  date  has  been  selected  for  the  operation  start 
date. 


Configuring  Time  Scale 

The  user  may  wish  to  switch  to  a  different  time  scale  to  change  the  timing  headers  on  the  Gantt 
chart.  The  time  scale  can  be  set  in  two  ways: 

•  Synchronization  menu  selection. 

•  Synchronization  Toolbar  dropdown 

The  currently  selected  Time  Scale  shows  a  dot  next  to  it  in  the  menu  and  is  displayed  in  the 
dropdown  in  the  Synchronization  toolbar.  See  Figure  C-31  for  more  details. 
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Figure  C-  31.  Time  Scale 


The  user  may  also  wish  to  remove  some  of  the  headers  in  the  Gantt  to  better  use  the  space.  By 
right-clicking  on  the  headers  and  choosing  from  the  drop  down  menu,  the  user  will  be  given 
the  option  to  hide  or  show  headers  by  checking  and  un-checking  the  checkboxes  for  the 
corresponding  headers. 
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'igure  C-  32.  Viewing  Options  for  Time  Scale 


Scrolling  to  the  Ends  of  a  Scheduled  Timing 

The  user  may  wish  to  quickly  scroll  to  the  beginning  or  the  end  of  a  timing  bar  that  extends  out 
of  the  current  visible  area.  This  can  be  accomplished  in  two  ways: 

•  Synchronization  menu  selections. 

•  Synchronization  Toolbar  buttons 

Select  the  element  you  wish  to  jump  to  the  beginning  or  the  end  of  either  in  the  tree  pane  or  by 
clicking  on  the  timing  element.  Make  the  appropriate  selection  shown  in  Figure  C-33. 

The  Gantt  chart  will  scroll  to  the  edge  of  the  timing  bar  of  the  selected  element. 
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Note:  If  multiple  schedule  timing  elements  are  present  the  beginning  is  the  earliest  timing 
element  and  the  end  is  the  latest  timing  element. 


Figure  C-  33.  Scroll  To  Ends  of  Timing  Bar 
Expanding  and  Collapsing  Tree 

The  user  may  wish  to  quickly  expand  or  collapse  the  display  of  elements  in  the  tree  pane.  This 
can  be  accomplished  in  two  ways: 

•  Synchronization  menu  selections. 

•  Synchronization  Toolbar  buttons 

Select  the  element  you  wish  expand  or  collapse  in  the  tree  pane  or  by  clicking  on  its  timing 
element.  Make  the  appropriate  selection  shown  in  Figure  C-34.  The  tree  pane  and  Gantt  chart  will 
expand  or  collapse  the  children  (and  their  children  and  so  on)  of  the  selected  element. 

Note:  If  no  element  is  selected  the  expand  and  collapse  function  will  expand  and  collapse  the 
root  element  in  the  tree. 


C-34 


Menu 


Toolbar 


Expands 

Collapses 

an 

an 

children 

children 

of  selected 

of  selected 

element 

element 

Figure  C-  34.  Expand  and  Collapse  Elements 
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Sketch  Module 
Capabilities 

Sketch  provides  the  ability  to  develop  plans  using  true  geographic  information.  Users  can 
associate  areas  on  the  map  to  new  and  existing  Mission  Analysis  and  Strategy  elements  to  give 
more  depth  to  their  operations. 

Processing  Procedures 

After  creating  COA  Sketch  elements  in  the  Synchronization  module,  users  can  associate  them 
with  one  or  more  shape  or  icon  on  the  map.  Sketch  has  the  functionality  to  create  new  COA 
Sketch  elements  and  associate  them  with  one  or  more  shape  or  icon  on  the  map.  Sketch  also 
allows  the  user  to  create  custom  layers  to  help  organize  the  map. 

Getting  Started 

Setting  the  Map  Source 

The  Map  Sketch  view  is  available  to  lay  out  CO  As  geographically  and  can  work  with  a  variety 
of  map  servers.  Microsoft  Aerial  is  the  default  map  view  that  is  opened  in  Map  Sketch.  If  there  is 
no  access  to  the  Internet,  Open  Map  can  be  started  on  the  lOPC-X  Server.  See  the  lOPC-X 
Administrator  for  starting  the  OpenMap  server.  The  map  source  can  be  set  in  two  ways: 

•  Sketch  menu  selection. 

•  Sketch  Toolbar  dropdown 

The  currently  selected  map  source  shows  a  dot  next  to  it  in  the  menu  and  is  displayed  in  the 


dropdown  in  the  Sketch  toolbar.  See  Figure  C-35  for  more  c 
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Figure  C-  35.  Map  Source 
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Adding  a  Shape  or  Icon 


Available  shapes  are  located  on  the  left  pane  of  the  Sketch  module.  See  Figure  C-36. 

To  draw  a  Basic  Shape,  select  the  type  of  shape  you  want  from  the  side  bar.  Click  and  hold  on 
the  map  while  dragging  across  the  map.  The  first  location  will  be  where  you  initially  clicked  and 
the  second  location  will  be  where  the  mouse  is  when  you  let  go.  These  two  locations  make  a 
bounding  box  around  the  shape  that  you  have  drawn. 

To  draw  a  Special  Shape,  select  the  type  of  shape  you  want  from  the  side  bar. 

•  If  drawing  a  point,  just  click  on  the  location  that  you  wish  the  point  to  exist. 

•  If  drawing  a  line,  click  and  hold  the  map  while  dragging  across  the  map.  The  line  will 
begin  where  you  initially  clicked  and  end  at  the  location  where  the  mouse  is  when  you  let 

go- 

•  If  drawing  a  polyline,  clicking  on  the  map  will  add  a  new  point  to  the  polyline.  Double 
click  to  add  the  last  point  of  the  polyline. 

•  If  drawing  a  polyshape,  clicking  on  the  map  will  add  a  new  point  to  the  polyshape.  The 
tool  will  automatically  draw  the  last  line  between  the  last  point  and  the  first  point.  A 
double  click  will  add  the  last  point  of  the  polyline. 
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Figure  C-  36.  Available  Shapes 
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Available  icons  are  located  in  a  tab  to  the  right  of  the  map,  next  to  the  Layers  tab.  See  Figure  C-37. 
To  add  an  icon  to  the  map,  drag  the  icon  from  the  tab  onto  the  map  at  the  desired  location. 
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Figure  C-  37.  Available  Icons 

Icons  are  stored  on  the  lOPC-X  server.  If  you  have  trouble  accessing  the  icons  or  wish  to  update 
what  icons  are  available,  see  the  COA  Sketch  Installation  Guide. 


After  dragging  or  drawing  the  shape/icon,  a  COA  Sketch  Objects  chooser  will  appear  with  all  the 
COA  Sketch  elements  currently  in  the  operation.  You  can  attach  a  shape  to  an  already  existing 
COA  Sketch  Object  or  create  a  new  COA  Sketch  object  to  associate  with  the  shape/icon.  See 

Figure  C-38. 
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New  Shape  Wizard 

Select  the  new  shape  association  and  press  "Next". 
New  COA  Sketch  Object 
Attach  to  Existing  COA  Sketch  Object 


Cancel 


Figure  C-  38.  New  Shape  Wizard 

Shapes  can  be  added  by  COA  element  type  or  by  Operation  hierarchy.  See  Figure  C-  39.  Adding 
Shapes.  The  ‘Type’  view  will  show  all  the  existing  elements  based  upon  the  different  types  of 
elements  that  are  in  the  system.  The  “Hierarchy”  view  simply  displays  the  same  view  that  is 
shown  in  the  synchronization  module. 

If  you  are  adding  a  new  element,  you  have  already  chosen  the  type  of  element  you  wish  to  create. 
The  Type  view  will  only  show  you  elements  that  are  of  that  type  or  elements  that  you  can  add 
the  selected  type  to.  If  you  are  choosing  an  existing  element,  then  the  Type  view  will  display  all 
existing  elements,  sorted  by  their  type. 

Select  the  element  you  wish  to  associate  with  the  new  shape  or  select  the  element  in  the 
hierarchy  tree  and  click  finish.  The  new  element  will  be  either  added  as  a  child  to  the  selected 
element  or,  if  the  element  cannot  have  children,  it  will  be  added  as  a  new  element  under  the  same 
element  as  the  selected  element. 
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Figure  C-  39.  Adding  Shapes 

Once  you  have  determined  the  shape  association,  you  need  to  decide  what  layer  to  add  it  to.  If  no 
layers  exist  you  will  be  prompted  to  create  a  new  Layer.  See  Figure  C-  40.  Adding  a  Layer.  When 
adding  a  new  layer,  you  will  have  the  option  to  “Share”  your  layer.  By  default,  other  users  may 
not  see  layers  you  have  created.  Select  the  “Share”  checkbox  if  you  wish  others  to  see  your  layer. 
If  the  desired  layer  already  exists  you  can  select  the  layer  and  click  finish. 


Note:  Auto  Layer  creation  is  not  available  when  creating  a  new  layer  while  adding  a  new  shape. 
Each  new  shape  will  need  to  be  added  to  a  custom  layer  initially.  They  may  be  removed  after  the 
shape  has  been  created. 
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Figure  C-  40.  Adding  a  Layer 
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The  shape  will  now  appear  on  the  map  and  will  be  added  to  the  Layers  tab  under  the  category  of 
object.  See  Figure  C-41. 
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Figure  C-41.  Sketch  with  Objects  Added 


Deleting  Shapes  from  the  Map 

When  you  delete  a  shape  from  the  map,  only  the  shape  is  deleted.  The  Mission  Analysis  or 
Strategy  element  remains  in  the  operation.  To  delete  the  entire  element,  see  page  C-26. 


To  delete  a  shape  or  icon,  first  select  the  shape  on  the  map  or  in  the  Layers  tab.  You  can  delete 
the  shape  by  either: 

•  Sketch  menu 

•  Sketch  toolbar 
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•  Workspace  toolbar 

•  Right  click  menu  (in  map  and  in  Layers  tab) 
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Figure  C-  42.  Delete  Shape  Variations 


Manipulating  shapes  between  layers 

The  user  may  remove  shapes/icons  from  eustom  layers,  move  shapes  between  layers,  and  eopy 
shapes  to  multiple  layers. 

To  remove  a  shape/icon  from  a  layer,  first  seleet  the  shape  on  the  map  or  in  the  Layers  tab.  You 
can  remove  the  shape/icon  by  either: 

•  Dragging  and  Dropping  the  shape  off  the  layer  and  into  the  “Shapes  Without  a  Layer” 
list.  (The  shape  will  only  be  displayed  on  this  list  if  the  shape  is  not  listed  in  any  other 
layer) 

•  Right  eliek  and  ehoose  “Remove  From  Layer”  in  drop  down  menu 

To  move  a  shape/ieon  to  a  new  layer,  first  seleet  the  shape  from  either  a  custom  layer  or  from  the 
“Shapes  Without  a  Layer”  list.  Drag  and  drop  the  shape/ieon  to  the  desired  eustom  layer.  The 
shape  will  be  removed  from  it’s  initial  layer  and  will  be  displayed  in  the  desired  layer. 
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To  copy  a  shape/icon  from  a  layer  (custom  or  auto)  to  another  custom  layer,  select  the  shape. 
While  holding  down  the  control  key,  select  the  shape  and  drag  and  drop  it  into  the  desired  layer. 
The  shape  will  now  be  displayed  in  both  layers. 


Editing  COA  Sketch  Element  Properties 


The  user  may  wish  to  update  information  about  a  COA  Sketch  element  (i.e.  Fact,  Operational 
Objective,  etc)  via  the  Sketch  module.  To  bring  up  the  editor  that  will  allow  for  modification  of 
the  element  associated  with  the  shape,  select  the  shape  either  in  the  map  view  or  in  the  Layers 
tab.  Right  click  on  the  shape  or  shape  element.  Choose  “Edit  Shape  Source”  from  the  drop  down 
menu.  See  Error!  Reference  source  not  found.3  for  further  information. 
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Figure  C-  43.  Edit  COA  Sketch  element  associated  to  Shape 


Editing  Shape  Properties 

The  user  may  wish  to  update  the  fill  color,  transparency,  line  color,  and  other  properties  for  an 
individual  shape.  There  are  three  ways  to  view  the  shape  editor,  See  Figure  C-44. 

First  select  the  shape  on  the  map  or  in  the  Layers  tab.  Then  use  one  of  these  methods  for  opening 
the  shape  editor. 

•  Right  Click  on  the  Shape 

•  Double  Click  on  the  Shape 

•  Sketch  Toolbar  Button 

•  Right  click  the  shape  in  the  layer  tab 
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Figure  C-  44.  Edit  Shape  Properties 

Shape  editors  are  unique  to  the  specific  shape  style,  but  Figure  C-45  shows  a  typical  shape  editor. 
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Figure  C-  45.  Typical  Shape  Editor 


A  shape’s  size  can  be  edited  by  clicking  and  dragging  on  any  of  the  Sizing  Handles  surrounding 
the  shape.  A  shape  may  also  be  rotated  by  clicking  and  dragging  the  rotation  angle.  See  Figure  C- 
46.  Shape  Handles. 
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Figure  C-  46.  Shape  Handles 

Special  shapes  do  not  have  the  same  shape  handles  as  the  basic  shapes  have.  However,  once 
selected,  each  point  that  makes  up  the  special  shape  is  displayed  with  a  handle  that  will  allow  the 
location  to  be  re-located  and  modified  individually,  as  shown  in  Figure  C-47. 
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Figure  C-  47.  Special  Shape  Handles 
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Adding  Custom  Layers 

Users  may  find  it  convenient  to  create  custom  layers  as  a  way  to  group  shapes.  The  custom 
layer’s  properties  can  be  edited  so  that  all  the  shapes  in  the  layer  have  the  same  characteristics.  If 
a  shape  appears  in  more  than  one  layer,  the  top  layer’s  properties  take  precedence. 

To  create  a  custom  layer,  click  on  the  add  layer  button  Map  Sketch  toolbar  as  shown  in  Figure  C- 
48.  Add  Layer... 


Figure  C-  48.  Add  Layer 

The  create  layer  window  opens;  see  Figure  C-  49.  New  Layer  Wizard.  The  New  Layer  Wizard  has  a 
few  options. 

•  Share  -  When  a  user  creates  a  new  layer  the  layer  will  be  private  to  the  user  who  created 
it.  If  the  user  wants  to  allow  other  users  to  work  or  view  the  new  layer  then  they  may 
share  it. 

•  Auto  -  If  a  user  wants  a  layer  to  display  a  certain  category  of  objects  (objectives,  facts, 
tactical  tasks,  etc.)  the  auto  layer  will  display  all  shapes  related  to  the  selected  object 
type.  Auto  layers  are  controlled  by  the  system  so  the  user  can  not  manually  add  or 
remove  shapes  from  the  layer. 

o  Filter  -  Will  filter  the  shapes  added  to  Auto  layers  by  shape  type.  A  user  must 
choose  a  filter  in  conjunction  with  an  auto  layer. 
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Figure  C-  49.  New  Layer  Wizard 
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To  edit  a  layer’s  properties,  select  the  layer  and  click  the  Edit  element  button  on  the  Map  Sketch 
toolbar  or  right  click  on  the  layer  name  and  choose  edit  from  the  drop  down  menu  as  shown  in 
Figure  C-  50.  Edit  Layer. 


Reordering  Layers 

The  order  of  the  layers  in  the  Layers  tab  is  important  in  determining  the  properties  of  a  shape. 
The  layer  on  the  top  takes  precedence.  For  example,  if  a  shape  is  in  more  than  one  layer  that  sets 
the  fill  color,  the  Layer  on  top  of  the  list  will  determine  the  color  of  the  shape.  Properties  of  a 
layer  can  be  overwritten  for  an  individual  shape  in  the  shape’s  editor.  See  Section  0  for  details  on 
opening  a  shape’s  editor.  To  modify  the  order  of  the  layers,  select  a  layer  in  the  Layer  tab.  Drag 
and  drop  the  layer  to  the  desired  location  in  the  list. 


Viewing  the  Longitude  and  Latitude  of  the  mouse  position 

The  Longitude  and  Latitude  display  at  the  bottom  left  comer  of  the  Sketch  screen  shows  the  user 
the  coordinates  of  the  mouse  pointer  in  the  current  Map  Sketch  map  source.  See  Figure  C-51. 


Figure  C-  51.  Longitude  and  Latitude 
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Zooming  on  the  Map 

Typical  Zooming  functionality  can  be  performed  on  the  map.  The  user  can  zoom  in,  zoom  out,  or 
zoom  to  a  shape  that  is  selected  in  the  Layers  tab.  If  a  user  has  multiple  shapes  selected  the  zoom 
to  will  zoom  to  a  center  point  between  the  selected  shapes.  You  can  access  the  zoom 
functionality  by  either: 


•  Sketch  menu 

•  Sketch  toolbar 


Locate  in  Synchronization  Module 

The  user  may  quickly  locate  the  COA  Sketch  element  associated  with  a  shape  from  within  the 
Synchronization  module  by  selecting  the  shape  and  then  clicking  the  icon  in  the  toolbar  as  shown 
in  Figure  C-53. 
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Figure  C-  53.  Locate  in  Synchronization  Module 
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Plan  Player 
Capabilities 

The  Plan  Player  provides  the  user  a  means  to  view  the  plan  as  it  goes  through  the 
Synehronization  (Gantt  ehart)  View  and  the  Map  Sketch  View  as  the  timing  of  different  elements 
come  into  and  out  of  focus 

Processing  Procednres 

By  default,  the  Player  is  displayed  at  the  bottom  of  the  Workspace.  To  hide  or  show  the  Player, 
go  to  the  View  menu.  A  checkmark  next  to  Player  indicates  it  is  shown  in  the  Workspace.  No 
checkmark  indicates  it  is  hidden.  Select  Player  in  the  View  menu  to  toggle  its  display. 
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Figure  C-  54.  Open  Player 


Getting  Started 

Setting  Up  the  Plan  Player 

In  order  to  use  the  Plan  Player,  the  timing  preferences  for  the  player  must  be  configured.  See 
Section  0  Plan  Player  Preferences. 

Using  the  Plan  Player 


Once  the  Timing  of  the  Operation  has  been  set  properly  you  can  use  the  Plan  Player  to  step 
through  the  plan.  To  start  the  Plan  Player  click  on  the  Play  button. 
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Figure  C-  55.  Plan  Player  Controls 
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If  you  wish  to  see  portions  of  the  plan  that  are  ahead  of  the  current  Play  position  you  can 
advance  through  the  plan  by  the  set  step  increments  by  clicking  on  the  fast  forward  button.  You 
may  also  drag  and  drop  the  progress  ticker  to  the  desired  location. 

If  you  wish  to  see  portions  of  the  plan  that  are  behind  the  current  Play  position  you  can  review 
the  plan  (by  the  set  step  increments)  by  clicking  on  the  rewind  button.  You  may  also  drag  and 
drop  the  progress  ticker  to  the  desired  location. 

While  the  plan  player  is  playing,  the  play  button  is  toggled  and  replaced  with  a  pause  button. 

Note:  You  cannot  modify  the  Synchronization  view  or  the  Sketch  View  while  the  Plan  Player  is 
in  play  mode,  the  Plan  Player  must  be  in  pause  mode  to  modify  these  views. 


Other  attributes  of  the  Plan  player  are  the  Start  date.  End  date  and  Current  date  of  Playback. 

Stop  Date  in 
Playback 
Range 
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Current 
Date  in 
Playback 


y 


UTC  w«d  Apt  29  00:00:00  2009  UTC  Wftd  6  00:00:00  2Q09  UTC  ^ 


Figure  C-  56.  Plan  Player 


Plan  Player  Notes 

During  play,  the  Team  Member  or  Reviewer  may  wish  to  make  a  note  at  a  specific  time  during 
the  plan.  These  notes  work  as  a  reminders  to  the  Team  Member  to  modify  something  about  the 
plan  or  the  view  of  the  plan.  This  will  allow  the  Team  Member  or  Reviewer  to  add  input  to  the 
plan  without  having  to  exit  out  of  play  mode  to  immediately  make  the  modifications. 


Adding  Notes 

A  user  can  Right  Click  on  the  player  while  it  is  playing  at  the  desired  time  location. 


Swap  Notes/Pushpins 


Adds  a  Note  to  the 
PlanPlayar  at  the 
selected  tune  location 


►  !► 


D+2  C 


Settings.., 

About  Adobe  Flash  Player  10... 


Figure  C-  57.  Right  Click  Add  A  Note 
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Adding  a  Note  will  open  a  Note  text  box  seen  in  Figure  C-  58.  Entering  a  Note. 


UserNanie  of 
person  entsermg  Note 
and  actual  Date 
Note  was  added 


Date  in  Pla3toack  that 
the  Note  was  added 


f  I 

I  ^  ^  I  New  j  I  Delete  j  |  Porre  j 


'  ►  !► 


D  00:00:00 


Addsmtiltiple 
Notes  in  the  seme 
time  location 


Figure  C-  58.  Entering  a  Note 


By  clicking  the  ‘New’  button  you  can  add  multiple  notes  in  the  same  location.  The  note  box  will 
display  the  date  and  time  the  note  was  entered  and  the  user  name  of  the  person  who  entered  the 
note.  Click  ‘Done’  after  you  have  finished  entering  the  note. 


Note:  If  the  show  notes  during  playback  option  is  checked  in  the  preferences  and  there  are 
multiple  notes  in  one  location  only  the  last  entered  note  will  be  displayed  during  playback  See 
page  C-55  on  how  to  set  Plan  Player  preferences. 


Once  a  Note  is  added  a  note  icon  appears  on  the  player  at  the  specified  time. 

Note 

Indicator 


(D-1)  Sun  May  3  OOiOOiO 

41  ^  1 - - 1 

D* 

Figure  C-  59.  Note  Indicator 
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Deleting  Notes 

Once  a  note  is  no  longer  useful  to  the  team,  it  may  be  removed  from  the  system.  By  opening  the 
note  and  clicking  the  delete  button  of  the  desired  note. 

Note:  Users  can  only  delete  Notes  that  they  have  created. 


Figure  C-  60.  Delete  Note 


Plan  Player  Pushpins 

During  play,  the  Team  Member  or  Reviewer  may  wish  to  make  a  note  of  a  specific  map  location 
as  well  as  which  map  view  (i.e.  Open  Map,  Microsoft  Aerial)  at  a  specific  time  during  the  plan. 
These  pushpins  work  as  location  indicators  that  can  be  used  to  change  the  focus  location  of  the 
Sketch  View  during  playback. 


Adding  Pushpins 


To  add  a  pushpin  to  the  Plan  Player  navigate  to  the  location  on  the  Map  Sketch 
reference,  right  click  on  the  Plan  Player  on  the  bar  at  the  desired  time  along  the 
select  Add  Pushpin. 


Add  Note  _ ^ 

AddsaPushputo  the 
Plan  Player  at  the 

Swap  Notes/Pushpins 

selected  time  location 

you  wish  to 
play  range  and 


0+2  C 

►  !►  i  About  Adobe  Flash  Player  10*.. 


Figure  C-  61.  Add  A  Pushpin 

Note:  To  add  a  pushpin  the  Map  Sketch  View  must  be  open. 
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Deleting  Pushpins 

To  delete  a  pushpin  from  the  Plan  Player  right  click  on  the  pushpin  and  select  Delete  Pushpin 
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Delete 
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1 

Add  Pushpin 
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! 
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j 

Figure  C-  62.  Delete  A  Pushpin 


Swapping  Notes  and  Pushpins 

While  the  user  is  adding  Notes  and  Pushpins  they  may  wish  to  add  both  at  the  same  location.  To 
view  whether  a  pushpin  may  be  in  the  same  location  as  a  note  right  click  on  the  Plan  Player  and 
select  Swap  Notes  /Pushpins. 


S'Aap 

NotesiPushpine 

'  Add  Note 

Add  Pushpin 

Swap  Notes/Pushpins 

i  Show  Redraw  Regions 

Debugger 

Settings. . . 

1  About  Adobe  Flash  Player  9 . . . 

Figure  C-  63.  Swapping  Notes  and  Pushpins 


C-54 


Setting  Plan  Player  Preferences 

The  user  can  set  the  playback  range,  Playback  Step  Increment,  whether  the  playback  repeats, 
displays  notes  and  goes  to  pushpins  during  playback,  and  what  type  of  view  display  on  the 
Synchronization  chart  is  shown.  To  set  these  preferences,  select  Preferences. . .  under  the  View 
menu.  Next,  click  on  the  Player  icon.  These  preferences  are  stored  on  a  per  user  basis. 
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Figure  C-  64.  Player  Preferences 

The  Playback  Range  will  need  to  be  modified  in  a  new  plan  before  the  Plan  Player  can  be  run 
successfully.  By  default,  the  range  uses  Alpha  Days.  Phases  may  be  used  once  a  default  set  of 
phases  have  been  set  up  on  the  Operation  editor.  Calendar  dates  may  also  be  used  once  an  alpha 
date  has  been  set  up  in  the  Operation  Editor.  See  0  for  further  details  on  the  Operation  Editor. 

Playback  Step  Increment  allows  the  user  to  determine  the  interval  of  the  play  back  step  per 
second.  For  example,  if  the  user  intends  to  review  a  plan  that  lasts  months,  it  may  be  more 
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beneficial  to  step  through  the  plan’s  actions  in  terms  of  days  or  weeks  instead  of  in  terms  of 
hours. 


Playback  Options  include  the  ability  to: 

•  Repeat  through  the  play  process  automatically 

•  Use/Ignore  pushpins  during  play  back 

•  Display/Ignore  notes  during  playback 

Under  ‘View  Display’,  the  Focus  mode  will  display  items  on  the  map  only  as  they  come  into 
focus  in  the  time  displayed  by  the  Synchronization  module.  When  playing  with  Persistence 
mode,  once  map  shapes  appear,  they  will  remain  while  in  play  back.  The 

Under  ‘View  Display’,  Focus  Range  is  used  to  determine  the  time  range  in  which  elements  are 
active  over  time  through  play  back.  For  example,  if  the  range  is  set  to  two  days,  then  the  play 
back  mode  will  display  all  elements  whose  activities  intersect  the  two  day  range. 

Under  ‘View  Display’,  Focus  Alignment  is  used  to  determine  from  where  within  the  focus  range 
the  exact  focus  should  be.  In  our  example  of  a  two  day  Focus  Range,  before  would  be  the 
beginning  of  day  one,  center  would  be  24  hours  later,  and  After  would  be  at  the  end  of  the  two 
days.  If  the  start  time  was  D+10  and  you  chose  to  align  your  focus  After  the  Focus  Range,  then 
the  modules  and  views  would  display  all  activities  occurring  D+8  through  D+10  initially. 
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Related  Processing 

This  paragraph  has  been  tailored  out. 

Data  Backup 

It  is  expected  that  the  System  Administrator  responsible  for  the  lOPC-X  Server  and  Database 
will  provide  regular  backups  of  data  to  ensure  protection  against  lost  data.  If  there  is  any 
question  on  protecting  lOPC-X  data,  please  contact  your  System  Administrator. 

Recovery  from  Errors,  Malfunctions,  and  Emergencies 

This  section  details  the  error  messages  that  one  may  encounter  while  using  the  COA  Sketch 
application. 


The  following  is  a  list  of  commonly  encountered  issues  with  COA  Sketch. 

Table  C- 1.  Encountered  Issues  and  Resolutions 


Issue  Resolution 

Not  receiving  dynamic  updates 

Re-open  COA  Sketch  in  web  browser.  If 
that  does  not  help,  then  see  COA  Sketch 
Installation  Guide 

Icons  not  available  in  Sketch 

See  COA  Sketch  Installation  Guide 

Menus  all  display  as  “null” 

Internationalization  is  not  correct,  see  COA 
Sketch  Installation  Guide. 

Workspace  Toolbar  disappeared 

Preferences  became  corrupt;  please 
reregister  the  data  model.  Note:  all  data  will 
be  lost!  See  COA  Sketch  Installation  Guide. 

Time  zones  are  not  available 

Preferences  became  corrupt;  please 
reregister  the  data  model.  Note:  all  data  will 
be  lost!  See  COA  Sketch  Installation  Guide. 

Please  see  COA  Sketch  Open  Problem  Reports  for  more  information  on  known  issues. 

Please  see  COA  Sketch  Enhancement  Reports  for  more  information  on  planned  enhancements. 

Messages 

This  paragraph  has  been  tailored  out. 

Quick-reference  Guide 

This  paragraph  has  been  tailored  out. 
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Future  Enhancements 

•  Ticker 

•  Lines  of  Effeet 

•  Operations,  Aetivities  and  Actions  (OAA)  Status 

•  Effect  Status 

Ticker 

Future  Enhancement 

Capabilities 

The  Tieker  displays  user-selected  information  eontinuously  through  a  repeatable  scroll  pattern. 
Elements  on  the  Ticker  are  deemed  of  high-importance  and  thus  require  frequent  updates  or 
monitoring. 


Processing  Procedures 


By  default,  the  tieker  is  set  to  be  hidden  on  the  Workspace.  To  hide  or  show  the  ticker,  go  to  the 
View  menu.  A  cheekmark  next  to  Ticker  indieates  it  is  shown  in  the  Workspace.  No  cheekmark 
indieates  it  is  hidden.  Select  Ticker  in  the  View  menu  to  toggle  its  display. 


Getting  Started 
Using  the  Ticker 

To  add  elements  to  the  Ticker,  seleet  a  plan  element  in  the  Synehronization  module  and  drag  it  to 
the  Ticker.  The  item  will  be  repeated  (copied)  to  the  Tieker.  The  information  serolls 
continuously  while  the  “Play”  icon  is  selected.  The  information  pauses  when  the  “Pause”  ieon  is 
seleeted.  To  “Fast  Forward”  or  “Rewind”  information  on  the  Ticker,  grab  the  eloek  hand  control 
and  move  counter-elockwise  for  information  to  seroll  right  (Rewind)  or  move  eloekwise  for 
information  to  seroll  left  (Fast  Forward).  See  Figure  C-  65.  Ticker.  To  remove  a  plan  element  from 
the  Ticker,  seleet  the  element  on  the  Ticker  and  drag  it  to  any  area  off  the  Ticker.  The  item  will 


no  longer 

3e 

displayed. 

Pause  / 

Start 

scrolling 

Drag  cbck  hand  to 
rewind  /  fast  forward 
scrolling 

Planning  element 
placed  on  Ticker 

1^.. 


Sample  Planned  Effect^' 


Figure  C-  65.  Ticker 

In  the  future,  the  triangle  representing  the  planning  element  will  display  assessment  information. 


Setting  Preferences 

The  user  can  set  whether  items  dragged  to  the  Ticker  are  inserted  in  the  dropped  loeation  or  at 
the  end  of  the  Ticker.  Scrolling  and  speed  ean  also  be  adjusted.  To  set  these  preferenees,  seleet 
Preferences. . .  under  the  View  menu.  Next,  eliek  on  the  Ticker  ieon.  See  Figure  C-  66.  Ticker 
Preferences  . 
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Figure  C-  66.  Ticker  Preferences 
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Lines  of  Effect 

Future  Enhancement 

Capabilities 

The  LOE  view  provides  the  hierarchical  structure  from  a  PEL  through  various  plan  levels  down 
to  tactical  tasks.  Symbol  color  indicates  status.  Eines  visually  depict  relationships  among  the 
elements  and  plans.  Each  plan  element  has  corresponding  PEL  number  information. 

Horizontal  lines  in  the  LOE  View  show  four  plan  types:  National  Implementation  Plan  (NIP), 
Strategic,  Operational,  and  Tactical.  Within  each  plan  type,  the  corresponding  plan  elements  can 
be  displayed  and  include  PELs,  Objectives,  Tasks,  and  Activities.  Plan  elements  are  shown  by 
expanding  the  plan,  i.e.,  selecting  the  triangle  next  to  the  plan  name.  Symbols  for  a  specific  plan 
element  line,  such  as  Objectives,  can  be  toggled  “On”  by  selecting  the  checkbox  for  that  line 
such  that  the  check  appears. 

Filtering  specific  plan  elements  in  the  LOE  View  is  accomplished  by  selecting  sections  in  the 
Flyover  view.  The  Flyover  view  is  comprised  of  four  sections,  one  for  each  plan  type.  For 
example,  selecting  a  NIP  PEL  will  display  all  lower-order  effects  and 

Operations/Tasks/ Activities  in  the  LOE.  Individual  effects  or  plan  elements  can  be  displayed  or 
hidden  by  holding  down  the  Control  key  and  selecting  the  Flyover  element  with  the  mouse.  A 
plan  type  with  no  plan  elements  will  appear  as  a  black  square  indicating  no  plan  elements  are 
available  for  selection  or  filtering. 

The  scale  anchor  points  (Less  Than,  Expected,  and  Greater  Than)  can  be  moved  along  the 
horizontal  axis  by  “grabbing”  with  the  mouse  and  sliding  left  or  right. 

Selecting  the  “Lines  of  Effecf’  checkbox  in  the  upper-right  comer  displays  associations  between 
plan  elements.  Lines  are  displayed  when  the  check  is  present  and  removed  when  the  check  is 
absent. 

Figure  C-  67.  Lines  of  Effect  Mock  Up  is  a  representation  of  what  LOE  module  would  look  like  once 
implemented. 
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Figure  C-  67.  Lines  of  Effect  Mock  Up 
Processing  Procedures 

Currently,  the  LOE  View  has  not  been  implemented;  however  you  ean  see  the  plaeeholder  of  the 
module  in  COA  Sketeh. 

Getting  Started 

To  see  the  LOE  module  placeholder,  open  Lines  of  Effect  in  the  Workspace’s  Modules  menu. 
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Figure  C-  68.  Lines  of  Effect  Placeholder 
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OAA  Status 

Future  Enhancement 

Capabilities 

The  OAA  Status  View  provides  both  plan  element  and  effect  status/trend  information  for  a 
selected  plan. 

The  operator  selects  an  available  plan  from  the  drop-down  box  located  on  the  right  side  of  the 
view.  The  upper- left  pane  contains  a  list  of  PEL(s)  for  the  selected  plan.  The  first  triangle  icon 
indicates  plan  element  status/trend  and  the  second  triangle  icon  indicates  effect  status/trend. 
Selecting  a  checkbox  in  the  PEL  pane  creates  a  status/trend  column  in  the  bottom-right  pane 
specific  to  that  PEL.  Additional  PEL(s)  columns  are  added  as  additional  PEL  are  selected 
(checked).  The  lower-left  pane  contains  all  plan  elements  viewable  through  a  tree  Expand  (select 
the  “+”  icon)  and  hidden  through  a  Collapse  (select  the  “-“icon).  Expanding  the  plan  produces 
corresponding  effect  status/trend  indicators  in  the  Effect  pane.  Figure  C-  69.  OAA  Status  Mock  Up  is 
a  representation  of  what  OAA  Status  module  would  look  like  once  implemented. 

OAA  Status  Matrix  View  i5>  x 


Figure  C-  69.  OAA  Status  Mock  Up 
Processing  Procedures 

Currently,  the  OAA  Status  Matrix  View  has  not  been  implemented;  however  you  can  see  the 
placeholder  of  the  module  in  COA  Sketch. 

Note:  the  data  displayed  in  the  OAA  Status  Matrix  is  dummy  data  not  related  to  the  currently 
open  operation. 

Getting  Started 

To  see  the  OAA  Status  module  placeholder,  open  OAA  Status  Matrix  in  the  Workspace’s 
Modules  menu. 
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GAA  Status  MatHx  (NGT  FULLY  IMPLEMENTED) 
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Figure  C-  70.  OAA  Status  Matrix  Placeholder 
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Effect  Status 
Future  Enhancement 

Capabilities 

See  GEMS-Final-Report  for  more  details  on  10  Assessment  View 

Processing  Procedures 

Currently,  the  10  Assessment  View  has  not  been  implemented;  however  you  can  see  the 
placeholder  of  the  module  in  COA  Sketch. 


Note:  the  data  displayed  in  the  10  Assessment  is  dummy  data  not  related  to  the  currently  open 
operation. 


Getting  Started 

To  see  the  10  Assessment  module  placeholder,  open  10  Assessment  in  the  Workspace’s  Modules 
menu. 


Figure  C-  71.  lO  Assessment  Placeholder 
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Notes 

Log  Files 

The  lOPCX  Server.out  file  is  automatically  generated  during  lOPC-X  execution.  It  contains 
detailed  information  regarding  errors  and  other  events  that  may  have  produced  output  while 
lOPC-X  modules  are  running.  The  log  file  is  stored  <WebLogic lOPC-X Domain> 
\servers\IOPCX_Server\logs.  The  default  path  of  <WebLogic  lOPC-X Domain>  is  something 
similar  to  C:\bea\user_projects\domains\IOPCX_Domain.  This  information  is  extremely 
valuable  in  troubleshooting  possible  issues  that  may  arise. 

Point  of  Contact 

Please  contact  the  lOPC-X  Program  Office  with  any  suggestions  for  enhancements  that  you  may 
have. 
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List  of  Acronyms 


AFRL 

Air  Force  Research  Laboratory 

AOC 

Air  Operations  Center 

CM  Capability 

Module 

COA 

Course  of  Aetion 

CONOPS 

Coneept  of  Operations 

10  Inform 

ation  Operations 

lOPC-X 

Information  Operations  Planning  Capability  -  Experiment 

JFCOM  Joint 

Forces  Command 

JMO 

Joint  Management  Office 

LOE 

Lines  of  Effect 

NIP  National 

Implementation  Plan 

OAA 

Operations,  Activities,  and  Actions 

PEL 

Prioritized  Effect  List 

POC 

Point  of  Contact 

RDT&E 

Research,  Development,  Test  and  Evaluation 

RHHu 

man  Effectiveness  Direetorate 

SCIF 

Sensitive  Compartmented  Information  Faeilities 

SCOM 

Software  Center  Operator  Manual 

SUM 

Software  Users  Manual 

SPVT 

Strategy  Planning  Visualization  Tool 

SSC  SD 

SPAWAR  Systems  Center,  San  Diego 

URL 

Uniform  Resource  Locator 

C-67 


APPENDIX  D  -  COA  SKETCH  EXTERNAL  INTEREACES  USE  CASES 


External  Interfaces  Use  Cases  and  Requirements 


Friendly  Order  of  Battle  (FRoB)  Use  Cases 

Use  Case  x.1:  User  displays  all  friendly  operating  locations  In  a  given 
area 

User  Story  /  Context  of  Use: 

•  In  the  course  of  developing  a  strategy,  the  Team  Member  or  Reviewer  may  wish  to 
know  what  friendly  units  are  in  a  specific  area  in  order  to  start  developing  possible 
maneuvers.  The  Team  Member  or  Reviewer  may  wish  to  do  this  intuitively  by 
designating  an  area  of  the  map  in  the  Sketch  View.  Since  the  Sketch  View  does  not 
represent  real-time  tracking  of  individual  friendly  units,  the  way  to  do  this  will  be  by 
viewing  friendly  operating  locations,  from  which  the  user  can  peruse  associated 
friendly  units. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Level 

Primary  Actor:  Team  member,  Reviewer 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  The  Sketch  View  is  Open. 

•  COA  Sketch  has  successfully  connected  to  a  system  of  record  (SOR)  and  retrieved 
friendly  operating  location  /  unit  data. 

Triggers:  The  team  member  decides  to  view  all  friendly  operating  locations  in  a  given  area. 

Guarantees: 

•  COA  Sketch  shows  the  user  all  the  friendly  operating  locations  within  the  requested 
area. 

Main  Success  Scenario: 

1 .  The  user  specifies  an  area  in  sketch  view 

2.  The  user  selects  a  “display  friendly  operating  locations”  option 

3.  The  user  selects  to  display  all  operating  locations 

4.  The  system  displays  all  friendly  operating  locations  in  the  selected  area 

Requirements: 


Use  Case  x.2:  User  displays  specific  friendly  operating  locations  In  a 
given  area 

User  Story  /  Context  of  Use: 

•  In  the  course  of  developing  a  strategy,  the  Team  Member  or  Reviewer  may  wish  to 
know  what  friendly  units  are  in  a  specific  area  in  order  to  start  developing  possible 
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maneuvers.  The  Team  Member  or  Reviewer  may  wish  to  do  this  intuitively  by 
designating  an  area  of  the  map  in  the  Sketeh  View.  Since  the  Sketch  View  does  not 
represent  real-time  tracking  of  individual  friendly  units,  the  way  to  do  this  will  be  by 
viewing  friendly  operating  locations,  from  which  the  user  can  peruse  associated 
friendly  units.  Additionally,  the  user  may  have  specific  operations  in  mind,  and  may 
wish  to  filter  operating  locations  to  meet  his/her  needs.  For  example,  the  user  may 
want  to  see  only  locations  with  a  specific  model  of  bomber  available,  or  those  with 
the  bomber  and  a  specific  type  of  store  item. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Level 

Primary  Actor:  Team  member.  Reviewer 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  The  Sketch  View  is  Open. 

•  COA  Sketch  has  successfully  cormected  to  a  SOR  and  retrieved  friendly  operating 
location/unit  data. 

Triggers:  The  team  member  decides  to  view  some  friendly  operating  locations  in  a  given 
area. 

Guarantees: 

•  COA  Sketch  shows  the  user  all  the  friendly  operating  locations  of  the  requested 
type/types  within  the  requested  area. 

Main  Success  Scenario: 

1 .  The  user  specifies  an  area  in  sketch  view 

2.  The  user  selects  a  “display  friendly  operating  locations”  option 

3.  The  user  selects  the  filters  that  he  /  she  wishes  to  apply  to  the  operating  locations. 
This  may  include  one  or  more  of  the  following: 

•  Minimum  /  maximum  number  of  runways 

•  Mobile  /  stationary  locations 

•  Whether  the  locations  support  air  operations 

•  Availability  of  specific  items 

•  The  presence  of  certain  types  of  friendly  units 

•  The  country  of  ownership 

•  The  service  in  charge  of  the  operating  location 

•  Availability  on  a  specific  date  /  dates 

Alternate  Scenario  1 : 

4.  To  perform  an  AND  type  of  operation  on  filters,  the  user  selects  more  than  one  filter 
option 

5.  Go  to  6 

Alternate  Scenario  2: 

4.  To  perform  an  OR  type  of  operation  on  filters,  the  user  selects  a  “select  additional 
operating  locations”  options,  then  repeats  the  process  from  step  3 

5.  Go  to  6 

Alternate  Scenario  3: 

4.  Where  appropriate,  options  will  have  a  NOT  modifier  that  the  user  can  select  to 
ensure  the  operating  location  does  not  have  the  options  included  in  that  filter  (i.e. 
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“NOT  service  =  Army”  would  indicate  all  operating  locations  except  those 
maintained  by  the  Army) 

5.  Go  to  6 

Main  Success  Scenario: 

6.  The  system  displays  the  friendly  operating  locations  of  the  type  specified  by  the  user 
in  the  selected  area 

Requirements: 


Use  Case  x.3:  User  hides  all  friendly  operating  locations  in  a  given 
area  from  the  Sketch  View 

User  Story  /  Context  of  Use: 

•  After  viewing  certain  or  all  of  the  friendly  operating  locations  in  a  given  area,  the  user 
may  decide  to  simplify  the  view  by  hiding  them  from  certain  portions  of  the  map. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Level 

Primary  Actor:  Team  member,  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  The  Sketch  View  is  Open. 

•  COA  Sketch  has  successfully  connected  to  a  SOR  and  retrieved  friendly  operating 
location/unit  data. 

•  Friendly  operating  locations  have  been  added  to  the  Sketch  View. 

Triggers:  The  team  member  decides  to  hide  all  friendly  operating  locations  from  a  given 
area  from  the  Sketch  View. 

Guarantees: 

•  COA  Sketch  hides  all  the  operating  locations  within  the  requested  area  from  the 
Sketch  View. 

•  This  process  will  alter  neither  the  COA’s  nor  the  plan’s  list  of  unit  numbers. 

Main  Success  Scenario: 

1 .  The  user  selects  an  area  in  sketch  view 

2.  The  user  selects  a  “hide  friendly  operating  locations”  option 

3.  The  user  selects  to  hide  all  operating  locations 

4.  The  system  hides  all  friendly  operating  locations  within  the  area  specified  from  the 
Sketch  View 

Requirements: 


Use  Case  x.4:  User  hides  specific  friendiy  operating  iocations  in  a 
given  area  from  the  Sketch  View 

User  Story  /  Context  of  Use: 

•  After  viewing  certain  or  all  of  the  operating  locations  in  a  given  area,  the  user  may 
decide  to  simplify  the  view  by  hiding  those  they  deem  unnecessary  from  certain 
portions  of  the  map. 

Scope:  User  to  COA  Sketch  Interaction 
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Level:  User  Level 

Primary  Actor:  Team  member,  Reviewer 
Supporting  Actors:  CO  A  Sketch 
Preconditions: 

•  The  Sketch  View  is  Open. 

•  COA  Sketch  has  successfully  connected  to  a  SOR  and  retrieved  friendly  operating 
location/unit  data. 

•  Friendly  operating  locations  have  been  added  to  the  Sketch  View. 

Triggers:  The  team  member  decides  to  hide  specific  types  of  friendly  operating  locations 
from  a  given  area  of  the  map. 

Guarantees: 

•  COA  Sketch  hides  from  the  Sketch  View  all  the  friendly  operating  locations  of  the 
indicated  type  within  the  requested  area. 

•  This  process  will  alter  neither  the  COA’s  nor  the  plan’s  list  of  unit  numbers. 

Main  Success  Scenario: 

1 .  The  user  select  an  area  in  Sketch  View 

2.  The  user  selects  a  “hide  friendly  operating  locations”  option 

3.  The  user  selects  filters,  as  described  in  x.2 

4.  The  system  hides  friendly  operating  locations  of  the  specified  type  within  the  area 
selected  from  the  Sketch  View 

Requirements: 

Use  Case  x.5:  User  manually  selects  friendly  units 

User  Story  /  Context  of  Use: 

•  In  the  course  of  developing  a  strategy,  the  Team  Member  or  Reviewer  may  wish  to 
manipulate  data  relevant  to  specific  friendly  units.  The  Team  Member  or  Reviewer 
may  do  this  while  browsing  the  friendly  units  associated  with  a  specific  operating 
location. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Level 

Primary  Actor:  Team  member.  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  has  successfully  connected  to  a  SOR  and  retrieved  friendly  operating 
location/unit  data. 

Triggers:  The  team  member  decides  to  select  specific  friendly  units. 

Guarantees: 

•  COA  Sketch  hides  from  the  Sketch  View  all  the  friendly  operating  locations  of  the 
indicated  type  within  the  requested  area. 

•  This  process  will  alter  neither  the  COA’s  nor  the  plan’s  list  of  unit  numbers. 

Main  Success  Scenario: 

1 .  The  user  select  a  friendly  operating  location 

2.  The  user  is  presented  with  a  list  of  friendly  unit  types  associated  with  the  selected 
operating  location 

3.  The  user  selects  one  or  more  of  the  unit  types  from  the  list 
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Requirements: 


Use  Case  x.6:  User  selects  all  friendly  units  In  a  given  area 

User  Story  /  Context  of  Use: 

•  In  the  course  of  developing  a  strategy,  the  Team  Member  or  Reviewer  may  wish  to 
manipulate  data  relevant  to  all  friendly  units  in  a  certain  area.  Rather  than  selecting 
each  operating  location  in  the  area,  then  manually  selecting  each  friendly  unit  in  order 
to  edit  them,  the  Team  Member  or  Reviewer  may  wish  to  do  this  intuitively  by 
designating  the  area  of  the  map  in  the  Sketch  View. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Level 

Primary  Actor:  Team  member.  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  The  Sketch  View  is  Open. 

•  COA  Sketch  has  successfully  connected  to  a  SOR  and  retrieved  friendly  operating 
location/unit  data. 

Triggers:  The  team  member  decides  to  select  all  friendly  units  in  a  given  area. 

Guarantees: 

•  COA  Sketch  selects  all  the  friendly  units  within  the  user-specified  area. 

Main  Success  Scenario: 

1 .  The  user  specifies  an  area  in  sketch  view 

2.  The  user  selects  a  “select  friendly  units”  option 

3.  The  user  chooses  an  option  to  select  all  friendly  units 

4.  The  system  sets  all  friendly  units  in  the  chosen  area  as  selected 
Requirements: 


Use  Case  x.  7:  User  selects  specific  friendly  units  in  a  given  area 

User  Story  /  Context  of  Use: 

•  In  the  course  of  developing  a  strategy,  the  Team  Member  or  Reviewer  may  wish  to 
manipulate  data  relevant  to  certain  friendly  units  in  a  specified  area.  Rather  than 
selecting  each  operating  location  in  the  area,  then  manually  selecting  the  friendly 
units  in  question  in  order  to  edit  them,  the  Team  Member  or  Reviewer  may  wish  to  do 
this  intuitively  by  designating  the  area  of  the  map  in  the  Sketch  View. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Level 

Primary  Actor:  Team  member.  Reviewer 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  The  Sketch  View  is  Open. 

•  COA  Sketch  has  successfully  connected  to  a  SOR  and  retrieved  friendly  operating 
location/unit  data. 

Triggers:  The  team  member  decides  to  view  all  friendly  units  of  the  specific  type/types  in  a 
given  area. 
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Guarantees: 

•  COA  Sketch  shows  the  user  all  the  friendly  units  of  the  requested  type/types  within 
the  requested  area. 

Main  Success  Scenario: 

1 .  The  user  specifies  an  area  in  sketch  view 

2.  The  user  selects  a  “display  friendly  units”  option 

3.  The  user  selects  the  user  selects  the  filters  that  he  /  she  wishes  to  apply  to  the  friendly 
units.  This  may  include  one  or  more  of  the  following: 

•  Unit  Type  (Air,  Electronic,  Ground,  etc.) 

•  Service  (Army,  AF,  etc.) 

•  Parent  country 

•  Ship  type 

•  Aircraft  type 

•  Artillery  type 

Alternate  Scenario  1 : 

4.  To  perform  an  AND  type  of  operation  on  filters,  the  user  selects  more  than  one  filter 
option 

5.  Go  to  6 

Alternate  Scenario  2: 

4.  To  perform  an  OR  type  of  operation  on  filters,  the  user  selects  a  “select  additional 
friendly  units”  option,  then  repeats  the  process  from  step  3 

5.  Go  to  6 

Alternate  Scenario  3: 

4.  Where  appropriate,  options  will  have  a  NOT  modifier  that  the  user  can  select  to 
ensure  the  operating  location  does  not  have  the  options  included  in  that  filter  (i.e. 
“NOT  service  =  Army”  would  indicate  all  operating  locations  except  those 
maintained  by  the  Army) 

5.  Go  to  6 

Main  Success  Scenario: 

6.  The  system  selects  the  friendly  units  of  the  type(s)  specified  by  the  user  in  the 
selected  area 

Requirements: 

Use  Case  x.8:  User  selects  all  friendly  units  that  could  operate/engage 
within  a  given  area 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  wish  to  know  what  friendly  units  are  available 
to  operate  in  a  specific  area  to  get  an  idea  of  possible  maneuvers,  or  to  see  if  they  will 
need  to  make  changes  to  unit  levels.  The  Team  Member  or  Reviewer  may  wish  to 
select  the  area  of  the  map  that  they  are  interested  in  operating  in,  and  should  be  able 
to  get  this  list  of  friendly  units. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Level 

Primary  Actor:  Team  member,  Reviewer 

Supporting  Actors:  COA  Sketch 
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Preconditions: 

•  The  Sketch  View  is  Open. 

•  COA  Sketch  has  successfully  connected  to  a  SOR  and  retrieved  friendly  operating 
location/unit  data. 

Triggers:  The  team  member  decides  to  view  all  friendly  units  that  could  operate  /  engage  in 
a  given  area. 

Guarantees: 

•  COA  Sketch  selects  all  the  friendly  units  capable  of  operating  within  the  requested 
area. 

Main  Success  Scenario: 

1 .  The  user  specifies  an  area  in  sketch  view 

2.  The  user  selects  a  “select  friendly  units  within  striking  range”  option 

3.  The  user  chooses  an  option  to  select  all  friendly  units 

4.  The  system  selects  all  friendly  units  whose  operating  radius  includes  all  of  the 
selected  area 

Requirements: 


Use  Case  x.9:  User  selects  specific  types  of  friendly  units  that  could 
operate/engage  within  a  given  area 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  wish  to  know  what  friendly  units  of  certain 
types  are  available  to  operate  in  a  specific  area  to  get  an  idea  of  possible  maneuvers. 
The  Team  Member  or  Reviewer  may  wish  to  select  the  area  of  the  map  and  be  able  to 
get  this  information. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Level 

Primary  Actor:  Team  member,  Reviewer 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  The  Sketch  View  is  Open. 

•  COA  Sketch  has  successfully  connected  to  a  SOR  and  retrieved  friendly  operating 
location/unit  data. 

Triggers:  The  team  member  decides  to  view  all  friendly  units  of  the  specific  type/types  that 
could  operate  /  engage  in  a  given  area. 

Guarantees: 

•  COA  Sketch  shows  the  user  all  the  friendly  units  of  the  requested  type/types  capable 
of  operating  within  the  requested  area. 

Main  Success  Scenario: 

1 .  The  user  specifies  an  area  in  sketch  view 

2.  The  user  selects  a  “select  friendly  units  within  striking  range”  option 

3.  The  user  selects  the  filters  that  he  /  she  wishes  to  apply  to  friendly  units  as  described 
in  X.7 

4.  The  system  selects  all  friendly  units  that  match  the  filter(s)  selected  whose  operating 
radius  includes  all  of  the  selected  area 
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Requirements: 


Use  Case  x.10:  User  adds  a  friendly  operating  location 

User  Story  /  Context  of  Use: 

•  While  developing  a  COA,  a  user  may  decide  that  part  of  what  makes  this  COA 
unique  will  be  the  introduction  of  new  operating  locations.  The  most  intuitive  way  to 
do  this  will  be  via  the  Sketch  View. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Level 
Primary  Actor:  Team  member 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  The  Sketch  View  is  Open. 

Triggers:  The  team  member  decides  to  add  an  operating  location  to  the  COA. 

Guarantees: 

•  The  current  COA  will  include  the  user-added  operating  location. 

•  The  COA  is  now  clearly  marked  as  having  information  not  based  on  SOR  data. 

•  The  non-SOR  data  designation  and  the  information  causing  this  designation  is 
included  in  data  that  is  considered  during  the  process  described  in  COA  Development 
use  cases  3.1 1  and  3.12. 

•  The  change  is  only  to  the  current  COA,  and  is  not  persisted  to  the  SOR. 

Main  Success  Scenario: 

1 .  The  user  selects  an  “add  operating  location”  option 

2.  The  user  selects  the  area  on  the  Sketch  View  where  he  /  she  would  like  to  add  the 
operating  location 

3.  The  system  prompts  the  user  to  enter  data  for  the  operating  location  including  (some 
or  all  of  these  entries  could  be  optional): 

•  Location  name 

•  Number  of  runways 

•  Mobile  capability 

•  Ability  to  support  air  operations 

•  The  service  operating  this  location 

•  The  operating  status 

•  ICAO 

•  Operating  status 

•  Parent  country 

4.  The  COA  adds  the  operating  location  to  the  information  about  the  friendly  order  of 
battle,  and  the  COA  is  marked  as  having  location  /  unit  information  not  supplied  by 
the  SOR  service 

Requirements: 
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Use  Case  x.11:  User  removes  a  friendly  operating  location  and  its 
associated  friendly  units 

User  Story  /  Context  of  Use: 

•  While  developing  a  CO  A,  a  user  may  add  operating  locations,  only  to  change  his  /  her 
mind  later  and  decide  to  delete  some  or  all  of  these  operating  locations. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Level 

Primary  Actor:  Team  member 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  The  Sketch  View  is  Open. 

Triggers:  The  team  member  decides  to  remove  an  operating  location  from  the  COA. 

Guarantees: 

•  The  current  COA  will  include  the  user-added  operating  location. 

•  If  the  deleted  operating  location  is  SOR-supplied,  the  COA  is  now  clearly  marked  as 
having  information  not  based  on  SOR  data,  if  this  was  not  already  the  case. 

•  The  non-SOR  data  designation  and  the  information  causing  this  designation  is 
included  in  data  that  is  considered  during  the  process  described  in  COA  Development 
use  cases  3.1 1  and  3.12. 

•  The  change  is  only  to  the  current  COA,  and  is  not  persisted  to  the  SOR. 

Main  Success  Scenario: 

1 .  The  user  selects  an  operating  location 

2.  The  user  selects  a  “delete  operating  location”  option 

3.  The  system  warns  the  user  that  this  will  also  delete  all  friendly  units  associated  with 
this  operating  location,  and  prompts  the  user  for  confirmation 

4.  The  COA  removes  the  operating  location  and  its  associated  friendly  units  from  the 
information  about  the  friendly  order  of  battle.  If  the  operating  location  was  SOR- 
supplied,  the  COA  is  marked  as  having  location  /  unit  information  not  supplied  by  the 
SOR  service  if  it  did  not  already  have  this  designation 

Requirements: 


Use  Case  x.12:  User  adds  friendly  units  to  a  friendly  operating 
location 

User  Story  /  Context  of  Use: 

•  While  developing  a  COA,  a  user  may  decide  that  part  of  what  makes  this  COA 
unique  will  be  the  introduction  of  new  friendly  units  to  an  existing  operating  location 
in  order  to  carry  out  certain  operations. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Level 
Primary  Actor:  Team  member 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  The  Sketch  View  is  Open. 

Triggers:  The  team  member  decides  to  add  friendly  units  to  an  operating  location. 


D-9 


Guarantees: 

•  The  current  COA  will  include  the  user-added  unit  data. 

•  The  COA  is  now  clearly  marked  as  having  information  not  based  on  SOR  data. 

•  The  non-SOR  data  designation  and  the  information  causing  this  designation  is 
included  in  data  that  is  considered  during  the  process  described  in  COA  Development 
use  cases  3.11  and  3.12. 

•  The  change  is  only  to  the  current  COA,  and  is  not  persisted  to  the  SOR. 

Main  Success  Scenario: 

1 .  The  user  selects  the  operating  location 

2.  The  user  selects  an  “add  friendly  units  to  operating  location”  option 

3.  The  user  selects  the  unit  type  from  a  presented  list  of  options 

4.  The  system  presents  the  user  with  a  dialog  with  data  fields  relevant  to  the  selected 
unit  type  that  user  fills  in. 

5.  The  COA  associates  the  unit  with  the  operating  location,  and  updates  the  friendly 
order  of  battle  data.  The  COA  is  marked  as  having  location  /  unit  information  not 
supplied  by  the  SOR  service 

Requirements: 


Use  Case  x.  13:  User  edits  information  for  one  type  of  unit 

User  Story  /  Context  of  Use: 

•  While  developing  a  COA,  a  user  may  decide  that  part  of  what  makes  this  COA 
unique  will  be  changing  the  number  of  available  friendly  units,  or  other  unit 
information  in  order  to  carry  out  specific  types  of  operations  that  might  otherwise  not 
be  possible. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Level 
Primary  Actor:  Team  member 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  The  Sketch  View  is  Open. 

•  Friendly  units  have  been  selected  in  ways  described  in  use  cases  x.5  -  x.9  above. 

•  All  friendly  units  selected  are  of  the  same  type  (i.e.  same  model  of  aircraft). 

Triggers:  The  team  member  decides  to  edit  the  information  for  the  selected  friendly  units 

(which  are  of  the  same  type)  for  the  current  COA. 

Guarantees: 

•  The  current  COA  will  include  the  user-edited  unit  information. 

•  The  COA  is  now  clearly  marked  as  having  information  not  based  on  SOR  data. 

•  The  non-SOR  data  designation  and  the  information  causing  this  designation  is 
included  in  data  that  is  considered  during  the  process  described  in  COA  Development 
use  cases  3.1 1  and  3.12. 

•  The  change  is  only  to  the  current  COA,  and  is  not  persisted  to  the  SOR. 

•  The  user  will  not  be  able  to  change  one  type  of  unit  into  another  using  this  method: 
this  data  will  not  be  editable. 

Main  Success  Scenario: 
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1 .  The  user  selects  an  “edit  unit  information”  option 

2.  The  system  presents  the  user  with  the  editable  data  held  in  common.  For  example,  a 
type  of  aircraft  might  present  the  following  fields  for  editing: 

•  Sortie  rate 

•  Quantity  (this  number  is  either  entered  directly,  or  more  likely,  the  user  enters  a 
percentage  to  modify  all  currently  selected  friendly  units  by) 

•  Comments 

•  Turn  time 

•  Assigned  crew  quantity 

•  Aircraft  configuration 

3.  The  CO  A  updates  its  friendly  order  of  battle  data  to  reflect  the  changes  made,  and  the 
COA  is  marked  as  having  location  /  unit  information  not  supplied  by  the  SOR  service 

Requirements: 


Use  Case  x.  14:  User  edits  information  for  muitipie  types  of  friendiy 
units 

User  Story  /  Context  of  Use: 

•  While  developing  a  COA,  a  user  may  decide  that  part  of  what  makes  this  COA 
unique  will  be  changing  the  number  of  available  friendly  units  in  order  to  carry  out 
specific  types  of  operations  that  might  otherwise  not  be  possible.  For  broad  types  of 
changes  like  this,  the  user  will  want  to  be  able  to  edit  many  different  types  of  troops 
simultaneously. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Level 
Primary  Actor:  Team  member 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  The  Sketch  View  is  Open. 

•  Friendly  units  have  been  selected  in  ways  described  in  use  cases  x.5  -  x.9  above. 
Triggers:  The  team  member  decides  to  edit  the  information  for  the  selected  friendly  units  for 

the  current  COA. 

Guarantees: 

•  The  current  COA  will  include  the  user-edited  unit  information. 

•  The  COA  is  now  clearly  marked  as  having  information  not  based  on  SOR  data. 

•  The  non-SOR  data  designation  and  the  information  causing  this  designation  is 
included  in  data  that  is  considered  during  the  process  described  in  COA  Development 
use  cases  3.1 1  and  3.12. 

•  The  change  is  only  to  the  current  COA,  and  is  not  persisted  to  the  SOR. 

Main  Success  Scenario: 

1 .  The  user  selects  an  “edit  unit  levels”  option 

2.  The  system  presents  the  user  with  the  editable  data  held  in  common.  For  multiple 
unit  types,  this  is  most  likely  to  include  only  quantity  information,  which  can  be  input 
either  as  a  direct  number,  or  more  likely,  as  a  percentage  of  the  unit’s  current  level 


D-11 


3.  The  CO  A  updates  its  friendly  order  of  battle  data  to  refleet  the  changes  made,  and  the 
COA  is  marked  as  having  location  /  unit  information  not  supplied  by  the  SOR  service 

Requirements: 


Use  Case  x.15:  User  reverts  COA  to  SOR  levels  for  operating 
locations  and  troop  levels 

User  Story  /  Context  of  Use: 

•  After  making  modifications  to  operating  locations  and  troop  levels,  the  user  may 
decide  to  scrap  all  changes  that  he  /  she  has  made.  The  user  may  have  made  other 
changes  to  the  COA  that  he  /  she  wishes  to  keep,  so  this  approach  is  more  logical  than 
deleting  the  entire  COA  and  starting  a  new  one. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Level 

Primary  Actor:  Team  member,  Reviewer 

Supporting  Actors:  COA  Sketch 

Preconditions: 

•  COA  Sketch  has  successfully  connected  to  a  SOR  and  retrieved  friendly  operating 
location/unit  data. 

Triggers:  The  team  member  decides  to  revert  the  friendly  order  of  battle  data  to  that 
supplied  by  the  SOR. 

Guarantees: 

•  The  COA  is  now  clearly  marked  as  having  information  supplied  by  the  SOR. 

•  The  SOR  data  designation  is  included  in  data  that  is  considered  during  the  process 
described  in  COA  Development  use  cases  3.1 1  and  3.12. 

Main  Success  Scenario: 

1 .  The  user  selects  a  “revert  to  SOR  data”  option 

2.  The  system  warns  the  user  that  he  /  she  will  lose  all  edited  unit  info  and  any  user- 
added  operating  locations,  and  waits  for  confirmation 

3.  If  the  user  confirms,  the  COA  loses  all  user-supplied  friendly  unit  and  operating 
location  data,  and  mirrors  the  most  current  data  supplied  by  the  SOR 

Requirements: 

Missing  Cases 

User  views  changes  between  COA  and  current  SOR. 

User  submits  changes  to  one  or  more  Operating  Locations  to  SOR. 

User  submits  changes  to  one  or  more  Units  to  SOR. 

COA  is  updated  with  new  data  from  SOR. 
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System  Interface  Use  Cases 

Use  Case  17.1:  MAAP  liaison  enters/modifies  Resource  and  Asset 
information 

User  Story  /  Context  of  Use: 

•  In  order  to  aid  the  Strategy  Planner  in  determining  how  long  it  will  take  to 
accomplish  each  effect,  the  planner  must  rely  on  the  resource  and  asset  information 
inputted  into  the  system  by  the  MAAP  liaison. 

•  The  Strategy  Planner  will  need  to  know  exactly  how  many  DMPI/Sortie  equivalents 
(DSEs)  are  available  per  ATO  cycle. 

•  The  MAAP  liaison  may  be  able  to  supply  this  information  directly  or  may  use  the 
COA  Sketch  system  to  determine  what  the  values  may  be. 

•  If  using  the  COA  Sketch  system  to  determine  these  values,  the  MAAP  liaison  will 
need: 

•  to  lookup  a  time  range  for  how  long  the  values  being  entered  are  valid; 

•  the  type,  location,  and  number  of  available  aircraft; 

•  statistics  on  each  aircraft  weapons  loads; 

•  and  provide  a  value  for  how  many  PGM  and  non-PGM  assets  it  will  take  to 
engage  a  target  successfully  (or  use  the  default). 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Resource  Developer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  A  COA  is  open  in  COA  Sketch. 

•  The  MAAP  view  is  open. 

Triggers:  The  MAAP  Liaison  needs  to  enter  or  modify  resource  and  asset  information. 

Guarantees: 

•  Additions  or  modifications  to  the  asset  and  resource  information  will  be  reflected  in 
the  Allocation  Planner. 

•  Additions  or  modifications  to  the  asset  and  resource  information  will  be  reflected  in 
the  MAAP  view. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  edit  Resource  and  Asset  information. 

2.  The  system  opens  the  XYZ  view  to  allow  the  user  to  enter  the  Resource  and  Asset 
information. 

Alternative  1: 

Requirements: 

Use  Case  17.2:  MAAP  Liaison  enters/modifies  values  for  the  PGM  and 
non-PGM  to  target  values 

User  Story  /  Context  of  Use: 
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•  In  order  to  aid  the  Strategy  Planner  in  determining  how  long  it  will  take  to 
accomplish  each  effect,  the  planner  must  rely  on  the  resource  and  asset  information 
put  into  the  system  by  the  MAAP  Liaison. 

•  Part  of  this  information  includes  determining  estimations  on  how  effective  the 
available  weaponry  will  be  against  a  target. 

•  For  an  added  level  of  granularity,  the  MAAP  Liaison  is  able  to  give  this  estimation 
for  each  aircraft’s  PGM  and  non-PGM  weaponry. 

•  However,  if  that  level  of  granularity  is  not  necessary,  the  MAAP  Liaison  may  also  set 
up  a  default  value  that  all  weapons  will  inherit. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  MAAP  liaison 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  A  COA  is  open  in  COA  Sketch. 

•  The  MAAP  View  is  open. 

Triggers:  The  MAAP  Liaison  would  like  to  enter  default  values  for  PGM  and  non-PGM 
estimation  for  successful  target  engagement. 

Guarantees: 

•  All  new  and  existing  available  aircraft  will  use  these  default  values  to  calculate 
DMPI/Sortie  relationships  unless  a  non-default  value  is  provided. 

•  Additions  or  modifications  to  the  default  values  will  be  reflected  in  the  Allocation 
Planner. 

•  Additions  or  modifications  to  the  default  values  will  be  reflected  in  the  MAAP  View. 

Main  Success  Scenario: 

Alternative  1: 

Requirements: 


Use  Case  17.3:  User  retrieves  asset  and  resource  updates  from  MAAP 
system  of  record 

User  Story  /  Context  of  Use: 

•  As  the  selected  COA  becomes  more  solidified  and  resources  and  assets  also  become 
more  solidified,  all  of  this  information  is  available  in  the  MAAP  system  of  record. 

•  As  long  as  the  COA  Sketch  system  has  access  to  this  system,  then  it  can  save  time  and 
effort  by  automatically  ingesting  this  information. 

•  This  will  free  up  MAAP  Liaisons  and  Strategy  Planners  from  manual  re-typing 
information  already  entered  into  a  system. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Strategy  Planner,  MAAP  Liaison 

Supporting  Actors:  COA  Sketch,  MAAP  system  of  record 

Preconditions: 

•  COA  Sketch  is  open. 
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•  A  plan/COA  is  open  in  COA  Sketch. 

•  The  user  knows  the  connection  information  required  to  establish  communication  with 
the  MAAP  data  system  of  record  OR  this  information  has  already  been  entered  into 
the  system. 

Triggers:  The  MAAP  Liaison/Strategy  Planner  would  like  to  automatically  ingest  MAAP 
Data  from  the  MAAP  system  of  record. 

Guarantees: 

•  If  Probability  of  Arrival  or  Damage  are  available,  the  scores  will  be  available  to  the 
Allocation  Planner  to  estimate  the  number  of  successfully  engaged  targets. 

•  If  Resource  or  Asset  information  is  available,  the  data  will  be  available  to  the  Allocation 
Planner  to  determine  the  number  of  DMPI/Sortie  equivalents  DSEs  per  ATO  period. 

•  Modifications  to  existing  values  that  are  currently  used  in  the  Allocation  Planner  will 
cause  re-calculation  in  the  Allocation  Plan. 

•  Additions  or  modifications  to  this  information  will  be  reflected  in  the  MAAP  View. 

Main  Success  Scenario: 

Alternative  1: 

Requirements: 


Use  Case  17.4:  User  analyzes  the  initial  force  structure  for  adequacy 

User  Story  /  Context  of  Use 

•  This  is  a  “first  look”  at  the  forces  which  have  either  been  tentatively  assigned  or  which  have 
been  made  available. 

•  The  staff  should  consider  the  relationship  between  specified  and  implied  tasks  and  available 
assets.  From  this  they  determine  if  they  have  the  air  capabilities  to  perform  all  the  specified 
and  implied  tasks. 

•  If  there  are  shortages,  this  is  the  time  to  identify  additional  or  alternative  resources  needed  for 
mission  success.  For  example,  if  the  tasks  include  supporting  the  ground  commander  and 
there  are  none  or  too  few  Close  Air  Support  (CAS)  assets,  this  is  the  time  to  identify  that 
shortfall. 

•  It  is  also  an  appropriate  time  to  examine  tanker  support  to  ensure  enough  assets  are  included. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
User  Impact: 

The  adequacy  of  air,  space,  and  information  capabilities  will  be  examined  repeatedly  and 
revised  often,  if  circumstances  allow,  throughout  the  crisis  action  planning  phase. 
Nonetheless,  the  sooner  a  significant  shortfall  in  the  resources  is  clearly  identified,  the 
more  likely  we  will  develop  a  plan  that  is  feasible. 

Primary  Actor:  Strategy  Planner,  Strategy  Guidance 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  plan/COA  is  open  in  COA  Sketch. 

•  The  Mission  Analysis  View  is  open. 

Triggers:  The  Strategy  Planner  receives  a  Warning  Order,  Planning  Order,  Alert  Order,  JFC 
OPLAN  or  OPORD  and  wishes  to  perform  Mission  Analysis. 
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Guarantees: 

•  The  user  will  be  able  to  store  this  analysis  of  forees  in  the  CO  A  Sketch  system. 

•  The  analysis  of  forces  will  be  available  to  the  team  members  via  the  Mission  Analysis  view. 

Main  Success  Scenario: 

1.  User  examines  guidance  documents  for  the  air,  space,  and  information  capabilities  the 
JFACC  should  expect  to  have  available. 

2.  User  considers  the  work  required  to  accomplish  the  specified  and  implied  tasks  and 
weighs  this  against  the  capabilities  identified  in  the  documents  to  be  made  available. 

3.  User  summarizes  his  analysis  and  prepares  recommended  changes  to  the  force  list. 

Alternative  1: 

Requirements: 

Current  techniques: 

Implementation  ideas: 

1 .  Temporal  and  geospatial  views  of  force  deployment  (friendly  and  adversary)  will  aid 
in  initial  force  structure  analysis. 

2.  Show  operational  reach  of  specified  forces.  Click  on  force  in  geospatial  view  and 
show  operational  reach  (basic  level  range  without  air  refueling). 

3.  Show  missile  range. 

4.  Fuel  and  re-supply  capabilities  of  friendly  air  bases.  Available  ramp  space,  munitions 
storage,  bunkers,  hardened  shelters,  fuel  hydrant  system. 

5.  Ground  radar  coverage,  SAMs,  CRCs,  air  defense  OPS  center? 

6.  Compatible  systems?  Can  AWACS  feed  into  their  system?  Do  they  have  ADSI 
system  to  integrate  air  and  ground  systems? 


Use  Case  17.5:  Display  indication  targets  have  been  assigned  to  a 
plan  element 

User  Story  /  Context  of  Use: 

•  The  Strategy  planner  or  TET  Liaison/team  member  will  need  to  make  sure  that 
targets  have  been  assigned  to  each  plan  element. 

•  The  Strategy  planner  will  want  to  make  sure  that  all  targets  that  may  be  affecting  the 
achievement  of  each  plan  element  and,  therefore,  the  plan  have  been  considered. 

•  The  TET  Liaison/team  member  will  need  to  do  the  same,  but  may  also  want  to  know 
targets  are  planned  against  high  level  plan  elements  that  need  to  be  removed  due  to 
the  addition  of  targets  to  low  level  plan  elements. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Strategy  Planner,  TET  Liaison 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  A  plan/COA  is  open  in  COA  Sketch. 

•  Synchronization  View  is  open. 

•  There  is  at  least  one  plan  element  with  targets  associated  to  it. 
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Triggers:  The  Strategy  Planner/TET  Liaison  wants  to  check  which  plan  elements  have 
targets  associated  to  them. 

Guarantees: 

•  The  user  will  be  able  to  see  at  a  glance  what  plan  elements  have  targets  associated 
with  them. 

Main  Success  Scenario: 

Alternative  1: 

Requirements: 


Use  Case  17.6:  Get  map  layer  data  from  IPOE  system  of  record 

User  Story  /  Context  of  Use: 

•  The  Intel  Liaison  or  Strategy  Planner  may  have  access  to  the  IPB  system  of  record.  If 
this  access  is  available,  it  would  greatly  aid  the  Strategy  Planner’s  success  and  the 
Intel  Liaison’s  responsibilities  if  this  information  could  be  automatically  ingested  into 
the  system.  This  ingestion  should  also  include  automatic  updates  to  the  data  for 
better  situational  awareness. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Intel  Liaison,  Strategy  Planner 

Supporting  Actors:  COA  Sketch,  IPOL  system  of  record 

Preconditions: 

•  COA  Sketch  is  open. 

•  The  user  knows  the  connection  information  required  in  establishing  communication 
with  the  IPOL  system  of  record  OR  this  information  has  already  been  entered  into  the 
system. 

Triggers:  Helpful  map  layer  data  is  available  in  the  IPB  system  of  record  that  the  team 

would  like  to  see  in  the  Sketch  View. 

Guarantees: 

•  The  map  layer  data  will  be  ingested  in  to  the  system. 

•  The  map  layer  data  will  be  available  to  the  plan/COA  that  the  IPOE  data  is  associated 
with. 

•  All  team  members  will  have  access  to  the  map  layer  data  for  the  plan/COA  the  data  is 
associated  with. 

Main  Success  Scenario: 

1 .  The  user  chooses  retrieve  map  layer  data  from  IPOE. 

2.  The  system  prompts  the  user  for  the  connection  data  for  the  IPOE  system. 

3.  The  user  provides  the  credentials  to  connect  to  the  IPOE  system. 

4.  The  system  connects  to  IPOE  and  displays  of  list  of  records. 

5.  The  user  selects  a  record. 

6.  The  system  loads  the  map  layer  data  from  the  selected  IPOE  record. 

7.  The  system  continues  to  receive  notifications  from  IPOE  when  the  loaded  map  layer 
changes  so  that  it  can  retrieve  the  new  changes. 

Alternative  1: 

Requirements: 
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Use  Case  17.7:  Get  DM  PI  information  due  to  area  selected  on  map 

User  Story  /  Context  of  Use: 

•  The  Team  Member  or  Reviewer  may  wish  to  know  what  DMPIs,  target  types  or 
categories,  or  total  DMPI  count  is  being  engaged  within  a  specific  area  of  the  map. 
The  Team  Member  or  Reviewer  may  wish  to  select  the  area  of  the  map  and  be  able  to 
get  his  information. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Level 

Primary  Actor:  Team  member,  Reviewer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  The  Sketch  View  is  Open. 

•  The  plan  contains  at  least  one  plan  element  that  has  targets  associated  with  it. 

Triggers: 

Guarantees: 

•  A  view  will  open  that  will  display  the  following  information  about  any  DMPI  that 
falls  within  the  user  selected  area: 

•  Total  DMPI  Count 

•  DMPI  count  by  target  type  or  category 

•  Description  of  each  DMPI 
Main  Success  Scenario: 

Alternative  1: 

Requirements: 


Use  Case  17.8:  User  analyzes  forces  required  and  available  for  each 
COA 

User  Story  /  Context  of  Use: 

•  Analyze  forces  required  and  available  for  each  COA.  This  initial  force  analysis  should  be 
refined  as  the  enemy  capabilities  and  intent  and  our  operational  concept  are  further  developed. 

•  Nonetheless,  an  initial  force  analysis  for  each  COA  is  essential. 

•  What  forces  has  higher  HQ  made  available  for  planning? 

•  What  forces  are  required  for  each  air  COA? 

•  When  are  forces  available  lAW  the  current  TPFDD  or  deployment  timetable? 

•  When  are  forces  required  for  each  COA? 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 
User  Impact:  This  is 

Primary  Actor:  Strategy  Planner,  Strategy  Guidance 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  A  plan/COA  is  open  in  COA  Sketch. 

•  The  Mission  Analysis  View  is  open. 

•  The  COA  Development  view  is  open. 

Triggers: 
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•  The  Strategy  Planner  has  completed  Mission  Analysis  and  now  wishes  to  begin  COA 
Development 

•  The  Strategy  Planner  wishes  to  use  the  system  to  aid  in  capturing  COA  Development 
data. 

Guarantees: 

•  The  user  will  be  able  to  store  the  specified  tasks  in  the  COA  Sketch  system 

•  The  specified  tasks  will  be  available  to  the  team  members  via  the  Mission  Analysis  view. 

Main  Success  Scenario: 

Alternative  1: 

Requirements: 

Current  techniques: 

Implementation  ideas: 

1 .  Review  based  on  the  CO  As  developed  (varies  by  COA) 

a.  Force  bed-down  could 

b.  Number  and  type  of  forces 

c.  Force  flow 

2.  The  tool  helps  capture  the  desired  force  flow  in  temporal,  geospatial,  tabular,  and 
spreadsheet  forms  for  each  COA  (if  they  differ). 


Use  Case  17.9:  Provide  a  selectable  target  list  In  a  area  to  a  user 

User  Story  /  Context  of  Use: 

•  In  order  to  aid  the  Strategy  Planner  in  determining  how  long  it  will  take  to 
accomplish  each  effect,  the  planner  must  rely  on  the  resource  and  asset  information 
inputted  into  the  system  by  the  MAAP  liaison. 

•  The  Strategy  Planner  will  need  to  know  exactly  how  many  DMPI/Sortie  equivalents 
(DSEs)  are  available  per  ATO  cycle. 

•  The  MAAP  liaison  may  be  able  to  supply  this  information  directly  or  may  use  the 
COA  Sketch  system  to  determine  what  the  values  may  be. 

•  If  using  the  COA  Sketch  system  to  determine  these  values,  the  MAAP  liaison  will 
need: 

•  to  lookup  a  time  range  for  how  long  the  values  being  entered  are  valid; 

•  the  type,  location,  and  number  of  available  aircraft; 

•  statistics  on  each  aircraft  weapons  loads; 

•  and  provide  a  value  for  how  many  PGM  and  non-PGM  assets  it  will  take  to 
engage  a  target  successfully  (or  use  the  default). 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Resource  Developer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  A  plan/COA  is  open  in  COA  Sketch. 

•  The  MAAP  view  is  open. 

Triggers:  The  MAAP  Liaison  needs  to  enter  or  modify  resource  and  asset  information. 
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Guarantees: 

•  Additions  or  modifications  to  the  asset  and  resource  information  will  be  reflected  in 
the  Allocation  Planner. 

•  Additions  or  modifications  to  the  asset  and  resource  information  will  be  reflected  in 
the  MAAP  view. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  edit  Resource  and  Asset  information. 

2.  The  system  opens  the  XYZ  view  to  allow  the  user  to  enter  the  Resource  and  Asset 
information. 

Alternative  1: 

Requirements: 


Use  Case  17.10:  Provide  a  target  list  and/or  a  number  of  targets  in  a 
area  to  a  user 

User  Story  /  Context  of  Use: 

•  In  order  to  aid  the  Strategy  Planner  in  determining  how  long  it  will  take  to 
accomplish  each  effect,  the  planner  must  rely  on  the  resource  and  asset  information 
inputted  into  the  system  by  the  MAAP  liaison. 

•  The  Strategy  Planner  will  need  to  know  exactly  how  many  DMPI/Sortie  equivalents 
(DSEs)  are  available  per  ATO  cycle. 

•  The  MAAP  liaison  may  be  able  to  supply  this  information  directly  or  may  use  the 
COA  Sketch  system  to  determine  what  the  values  may  be. 

•  If  using  the  COA  Sketch  system  to  determine  these  values,  the  MAAP  liaison  will 
need: 

•  to  lookup  a  time  range  for  how  long  the  values  being  entered  are  valid; 

•  the  type,  location,  and  number  of  available  aircraft; 

•  statistics  on  each  aircraft  weapons  loads; 

•  and  provide  a  value  for  how  many  PGM  and  non-PGM  assets  it  will  take  to 
engage  a  target  successfully  (or  use  the  default). 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Resource  Developer 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•  COA  Sketch  is  open. 

•  A  plan/COA  is  open  in  COA  Sketch. 

•  The  MAAP  view  is  open. 

Triggers:  The  MAAP  Liaison  needs  to  enter  or  modify  resource  and  asset  information. 

Guarantees: 

•  Additions  or  modifications  to  the  asset  and  resource  information  will  be  reflected  in 
the  Allocation  Planner. 

•  Additions  or  modifications  to  the  asset  and  resource  information  will  be  reflected  in 
the  MAAP  view. 

Main  Success  Scenario: 
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1 .  The  user  chooses  to  edit  Resource  and  Asset  information. 

2.  The  system  opens  the  XYZ  view  to  allow  the  user  to  enter  the  Resource  and  Asset 
information. 

Alternative  1: 

Requirements: 


Use  Case  17.11:  Strategy  Planner  enters  Apportionment  Guidance 
data  into  the  system. 

User  Story  /  Context  of  Use: 

•During  Mission  Analysis  and  throughout  the  campaign,  the  JFC  will  provide  apportionment 
guidance  to  the  Strategy  Team.  This  guidance  will  aid  the  team  in  determining  exactly  how 
much  focus  should  be  made  on  specific  target  and  mission  types.  By  entering  this  information 
into  the  system,  the  Strategy  Planner  will  provide  the  system  with  information  to  aid  the  team  in 
determining  how  well  the  current  plan  is  following  this  guidance. 

•The  service  component  commander  may  wish  to  elaborate  on  the  Apportionment  Guidance  set 
forth  by  the  JFC.  This  guidance  will  aid  the  team  in  determining  exactly  how  much  focus  should 
be  made  on  specific  target  and  mission  types.  By  entering  this  information  into  the  system,  the 
Strategy  Planner  will  provide  the  system  with  information  to  aid  the  team  in  determining  how 
well  the  current  plan  is  following  this  guidance. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 

Primary  Actor:  Strategy  Planner,  Strategy  Guidance 
Supporting  Actors:  COA  Sketch 
Preconditions: 

•A  plan/COA  is  open  in  COA  Sketch. 

•The  Mission  Analysis  View  is  open. 

Triggers: 

•The  Strategy  Planner  has  received  the  JFC’s  apportionment  guidance  and  now  wishes  to  enter  it 
into  the  system. 

•The  Strategy  Planner  has  received  the  service  component  commander’s  apportionment 
guidance  and  now  wishes  to  enter  it  into  the  system. 

Guarantees: 

•The  JFC’s  apportionment  guidance  will  be  stored  within  the  COA  Sketch  system. 

•The  JFC’s  apportionment  guidance  will  be  made  available  to  all  team  members  via  the  Mission 
Analysis  view. 

•The  service  component  commander’s  apportionment  guidance  will  be  stored  within  the  COA 
Sketch  system. 

•The  service  component  commander’s  apportionment  guidance  will  be  made  available  to  all 
team  members  via  the  Mission  Analysis  view. 

•Adding  or  updating  this  data  will  reflect  the  apportionment  guidance  comparison  displayed  in 
the  Allocation  Planner. 

Main  Success  Scenario: 

1 .  The  user  chooses  to  enter  Apportionment  Guidance  data  into  the  system. 

2.  The  system  displays  an  editor  window  for  entering  the  Apportionment  Guidance  data. 
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3. 

4.  The  user  enters  the  data  and  saves  the  ehanges. 

5.  The  system  stores  the  ehanges. 

Alternative  1: 

1 .  The  user  chooses  to  modify  Apportionment  Guidance  data. 

2.  The  system  displays  the  Apportionment  Guidance  editor  window  with  the  current 
Apportionment  Guidance  data. 

3.  The  user  modifies  the  data  and  saves  the  changes. 

4.  The  system  stores  the  changes. 

Requirements: 


Use  Case  17.12:  Import  IWPC  Plan  Into  CO  A  Sketch 

User  Story:  While  using  COA  Sketch  the  user  might  want  to  view  a  plan  inside  of 
IWPC.  This  plan  can  be  loaded  and  displayed  as  if  it  were  a  plan  originating  from  COA 
Sketch. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Operator 

Support  Actors:  COA  Sketch,  IWPC 

Preconditions: 

1 .  IWPC  is  functional 

2.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  User  decides  to  view  IWPC  plan  in  COA  Sketch. 

Guarantees: 

•  IWPC  plan  data  will  not  stored  in  two  places. 

Main  Success  Scenario: 

5.  User  activates  the  import  function. 

6.  A  list  of  IWPC  plans  is  presented  to  the  user. 

7.  The  user  selects  a  plan  to  import. 

8.  The  system  determines  if  the  plan  is  been  previously  imported  and  saved. 

9.  If  plan  has  not  been  imported,  the  plan  data  is  loaded  from  IWPC. 

10.  COA  Sketch  a  new  plan  process  is  created  using  the  IWPC  plan  data. 

Alternative  1: 

1 .  If  plan  has  been  imported,  the  COA  Sketch  plan  process  is  found. 

2.  The  plan  process  is  then  loaded,  pulling  required  data  from  IWPC. 

Finish: 

1 .  The  plan  process  data  is  returned  to  the  client. 

2.  The  plan  process  data  is  parsed  and  data  objects  are  created. 

3.  Objects  with  COA  Sketch  specific  data  are  marked  as  new  objects. 

Use  Case  17.13:  Open  COA  Sketch  Plan  Process 

User  Story:  User  wants  to  view  a  persisted  plan  in  the  COA  Sketch  client. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
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Primary  Actor:  Operator 

Support  Actors:  CO  A  Sketch,  IWPC 

Preconditions: 

1 .  IWPC  is  functional 

2.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  User  decides  to  view  a  COA  Sketch  plan  process. 

Guarantees: 

•  Plan  data  will  be  saved  as  it  is  edited. 

Main  Success  Scenario: 

1 .  User  activates  the  open  function. 

2.  A  list  of  plan  processes  is  presented  to  the  user. 

3.  The  user  selects  a  plan  process  to  open. 

4.  When  COAs  are  being  loaded,  the  system  checks  if  it  is  an  IWPC  plan. 

5.  If  the  COA  is  from  IWPC,  the  plan  data  is  loaded  from  there. 

6.  If  the  COA  is  not  from  IWPC,  the  COA  data  is  loaded  from  the  COA  Sketch 
persistent  store. 

7.  The  plan  process  data  is  parsed  and  data  objects  are  created. 

8.  Objects  are  marked  as  not  new. 

9.  Phase  data  is  selected  by  the  system. 

10.  Skip  to  step  12. 

Alternative  1: 

10.  If  multiple  Phase  set  exist  in  the  COAs,  a  list  of  phase  data  sets  is  presented  to  the 
user. 

11.  The  user  selects  the  Phase  set  to  use  for  the  plan  process. 

Finish: 

12.  The  phase  data  is  set  for  the  plan  process. 

Use  Case  17.14:  Export  COA  to  IWPC  as  a  New  Plan 

User  Story:  The  user  wants  to  share  a  COA  that  has  been  created  with  the  users  of 
IWPC. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Operator 

Support  Actors:  COA  Sketch,  IWPC 

Preconditions: 

3.  IWPC  is  functional 

4.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  The  COA  Sketch  COA  is  ready  to  be  viewed  by  the  users  of  IWPC. 

Guarantees: 

•  Data  that  can  be  stored  in  IWPC  will  be  removed  from  COA  Sketch  persistent 
store. 

•  Data  stored  in  COA  Sketch  can  be  mapped  to  IWPC  objects. 

Main  Success  Scenario: 

1 .  The  user  activates  the  export  function. 

2.  The  system  determines  which  COAs  can  be  exported-  they  have  to  be  not  empty 
and  saved. 
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3.  A  list  of  exportable  plans  is  displayed  to  the  user. 

4.  The  user  seleets  the  COA  to  export. 

5.  Basie  export  data  and  phases  are  sent  to  the  serviee. 

6.  The  plan  process  data  for  the  COA  is  loaded. 

7.  A  new  IWPC  plan  is  created  from  the  COA,  plan  process  and  phase  data. 

8.  When  the  COA  data  is  added  to  the  new  IWPC  plan,  its  non  COA  Sketch  specific 
data  is  removed  from  the  COA  Sketch  persisted  store. 

9.  When  the  phase  data  is  added  to  the  new  IWPC  plan,  the  related  plan  process 
phase  data  is  removed  from  COA  Sketch  persisted  store. 

10.  When  the  COA  element  data  is  added  to  the  new  IWPC  plan,  its  non  COA  Sketch 
specific  data,  and  causal  links  are  removed  from  the  COA  Sketch  persisted  store. 

1 1 .  Assumptions  are  concatenated  into  a  single  assumption  and  set  in  the  new  plan. 
They  also  remain  in  the  COA  Sketch  persisted  store. 

12.  Facts  are  concatenated  into  a  single  fact  and  set  in  the  new  plan.  They  also  remain 
in  the  COA  Sketch  persisted  store. 

13.  Tasks  are  concatenated  into  specified,  implied  and  essential  tasks  and  set  in  the 
new  plan.  They  also  remain  in  the  COA  Sketch  persisted  store. 

14.  If  the  name  is  already  used,  an  incremental  number  is  appended  to  the  name  until 
a  unique  name  is  created  and  displayed  to  the  user  for  approval. 

15.  The  new  plan  is  sent  to  IWPC  for  persisting. 

Alternative  1: 

6.  The  system  could  not  export  the  data,  for  example  the  connection  to  IWPC  could 
not  be  established. 

7.  The  system  informs  the  user  the  export  failed 

8.  The  COA  remains  in  the  COA  Sketch  persisted  data  store. 

Use  Case  17.15:  Load  Mission  Statement  from  iWPC 

User  Story:  When  plan(s)  are  loaded  from  IWPC  a  mission  statement  must  be  defined 
for  the  plan  process.  The  statement  will  be  a  concatenation  of  all  unique  statements  from 
each  plan. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

1 .  IWPC  is  functional 

2.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  Each  individual  mission  statement  will  not  be  altered  during  concatenation 
process. 

Main  Success  Scenario: 

1 .  The  user  selects  to  open  a  plan  process. 

2.  The  system  loads  all  IWPC  plans  associated  with  the  process. 

3.  The  system  compares  the  mission  statements  of  all  IWPC  plans  and  creates  a  list 
of  unique  mission  statements 
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4.  The  system  prompts  the  user  to  seleet  the  mission  statement  for  the  plan  proeess. 

5.  The  system  sets  the  plan  proeess  mission  statement  to  the  seleeted  statement. 

i.  Any  newly  ereated/exported  CO  As  will  have  the  mission  statement  set  in 
the  plan  proeess. 

ii.  The  individual  IWPC  plans  will  remain  unique  unless  the  mission 
statement  is  edited  in  COA  Sketch.  If  it  is  edited,  all  the  exported  COA 
mission  statements  will  be  updated  with  the  new  mission  statement. 

Use  Case  17.16:  Persist  Mission  Statement  to  iWPC 

User  Story:  When  the  user  persists  the  plan,  the  mission  statement  must  be  stored  be  to 
IWPC. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

3.  IWPC  is  functional 

4.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  process  has  been  persisted. 

Guarantees: 

•  Mission  statement  will  be  stored  back  to  IWPC. 

Main  Success  Scenario: 

1 .  Plan  data  loaded  from  IWPC. 

2.  Mission  statement  data  is  received. 

3.  Mission  statement  is  marked  as  changed.  If  not  changed  then  stop. 

4.  If  changed  set  mission  statement  in  each  plan  object. 

5.  Send  plan  changes  back  to  IWPC. 

Use  Case  17.17:  Persist  Phase  Changes  to  iWPC 

User  Story:  Phases  have  changed  and  the  plan(s)  in  IWPC  need  to  be  updated  with  the 
changes. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

5.  IWPC  is  functional 

6.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Phases  have  changed  when  persisted. 

Guarantees: 

•  Phase  data  is  stored  to  IWPC. 

Main  Success  Scenario: 

1 .  Plan  data  is  loaded  from  IWPC. 

2.  Phase  changes  are  extracted  from  the  persistence  data. 

3.  The  original  phase  objects  are  found. 

4.  Deleted  phase  are  removed  from  the  original  set. 
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5.  Phases  are  updated  in  the  original  set. 

6.  New  phases  are  added  to  the  original  set. 

7.  For  each  plan,  the  phases  are  updated  to  match  the  updated  set  previously  created. 

8.  The  plan  updates  for  each  will  be  sent  back  to  IWPC. 

Use  Case  17.18:  Load  Assumptions  for  IWPC  Plan 

User  Story:  Assumptions  need  to  be  loaded  from  an  IWPC  plan  and  made  into  a  COA 
Sketch  object. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

7.  IWPC  is  functional 

8.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  Assumption  data  is  not  lost  during  loading. 

Main  Success  Scenario: 

1.  Plan  is  loaded  from  IWPC. 

2.  Assumption  data  is  pulled  from  the  plan. 

3.  RTF  meta  data  is  cleaned  off. 

4.  If  assumption  is  not  an  empty  string,  create  new  assumption  for  COA  Sketch. 

Use  Case  17.19:  Load  Facts  for  IWPC  Plan 

User  Story:  Facts  need  to  be  loaded  from  an  IWPC  plan  and  made  into  a  COA  Sketch 
object. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

9.  IWPC  is  functional 

10.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  Fact  data  is  not  lost  during  loading. 

Main  Success  Scenario: 

1 .  Plan  is  loaded  from  IWPC. 

2.  Fact  data  is  pulled  from  the  plan. 

3.  RTF  meta  data  is  cleaned  off. 

4.  If  fact  is  not  an  empty  string,  create  new  fact  for  COA  Sketch. 

Use  Case  17.20:  Load  Specified  Tasks  for  IWPC  Plan 

User  Story:  Specified  Tasks  need  to  be  loaded  from  an  IWPC  plan  and  made  into  a  COA 
Sketch  object. 
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Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

1 1 .  IWPC  is  functional 

12.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  Specified  Task  data  is  not  lost  during  loading. 

Main  Success  Scenario: 

1 .  Plan  is  loaded  from  IWPC. 

2.  Specified  Task  data  is  pulled  from  the  plan. 

3.  RTF  meta  data  is  cleaned  off 

4.  If  specified  task  is  not  an  empty  string,  create  new  task  for  COA  Sketch. 

5.  Essential  tasks  cannot  be  distinguished  and  are  filtered  out. 

Use  Case  17.21:  Load  Implied  Tasks  for  IWPC  Plan 

User  Story:  Implied  Tasks  need  to  be  loaded  from  an  IWPC  plan  and  made  into  a  COA 
Sketch  object. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

13.  IWPC  is  functional 

14.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  Implied  Task  data  is  not  lost  during  loading. 

Main  Success  Scenario: 

1 .  Plan  is  loaded  from  IWPC. 

2.  Implied  Task  data  is  pulled  from  the  plan. 

3.  RTF  meta  data  is  cleaned  off. 

4.  If  Implied  Task  is  not  an  empty  string,  create  new  task  for  COA  Sketch. 

5.  Essential  Tasks  cannot  be  distinguished  and  are  filtered  out. 

Use  Case  17.22:  Persist  Assumptions  to  IWPC  Pian 

User  Story:  The  user  has  changed  the  assumptions  and  wants  to  persist  them  back  to 
IWPC. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

15.  IWPC  is  functional 
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16.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  persisted  back  to  IWPC. 

Guarantees: 

•  Assumption  data  from  other  plans  will  not  be  stored  in  current  plan  being 
persisted. 

Main  Success  Scenario: 

1 .  User  alters  the  assumption  pulled  from  IWPC. 

2.  User  activates  the  persistence  function. 

3.  The  new  value  is  stored  in  the  corresponding  plan  object. 

4.  Changes  are  sent  to  IWPC. 

Alternative  1: 

1 .  User  deletes  the  assumption  pulled  from  IWPC  or  no  assumption  existed  in  plan 
to  begin  with. 

2.  User  creates  new  assumptions  in  COA  Sketch. 

3.  User  activates  the  persistence  function. 

4.  The  COA  Sketch  assumptions  are  persisted. 

5.  The  full  list  of  assumptions  is  loaded. 

6.  The  list  is  concatenated  into  a  single  assumption  and  stored  in  the  corresponding 
plan  object. 

7.  Changes  are  sent  to  IWPC. 

Use  Case  17.23:  Persist  Facts  to  IWPC  Plan 

User  Story:  The  user  has  changed  the  acts  and  wants  to  persist  them  back  to  IWPC. 

Scope:  COA  Sketch  plan  service 

Level:  System  Goal 

Primary  Actor:  COA  Sketch  System 

Support  Actors:  IWPC 

Preconditions: 

17.  IWPC  is  functional 

18.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  persisted  back  to  IWPC. 

Guarantees: 

•  fact  data  from  other  plans  will  not  be  stored  in  current  plan  being  persisted. 
Main  Success  Scenario: 

1 .  User  alters  the  fact  pulled  from  IWPC. 

2.  User  activates  the  persistence  function. 

3.  The  new  value  is  stored  in  the  corresponding  plan  object. 

4.  Changes  are  sent  to  IWPC. 

Alternative  1: 

1 .  User  deletes  the  fact  pulled  from  IWPC  or  no  fact  existed  in  plan  to  begin  with. 

2.  User  creates  new  facts  in  COA  Sketch. 

3.  User  activates  the  persistence  function. 

4.  The  COA  Sketch  acts  are  persisted. 

5.  The  full  list  of  facts  is  loaded. 

6.  The  list  is  concatenated  into  a  single  fact  and  stored  in  the  corresponding  plan 
object. 
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7.  Changes  are  sent  to  IWPC. 

Use  Case  17.24:  Persist  Tasks  to  IWPC  Plan 

User  Story:  The  user  has  ehanged  the  tasks  and  wants  to  persist  them  back  to  IWPC. 

Scope:  COA  Sketch  plan  service 

Level:  System  Goal 

Primary  Actor:  COA  Sketch  System 

Support  Actors:  IWPC 

Preconditions: 

19.  IWPC  is  functional 

20.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  persisted  back  to  IWPC. 

Guarantees: 

•  Task  data  from  other  plans  will  not  be  stored  in  current  plan  being  persisted. 

Main  Success  Scenario: 

1 .  User  alters  the  specified  or  implied  task  pulled  from  IWPC. 

2.  User  activates  the  persistence  function. 

3.  The  new  value  is  stored  in  the  corresponding  plan  object. 

4.  Changes  are  sent  to  IWPC. 

Alternative  1: 

1 .  User  deletes  the  specified  or  implied  task  pulled  from  IWPC  or  no  task  existed  in 
plan  to  begin  with. 

2.  User  creates  new  tasks  in  COA  Sketch. 

3.  User  activates  the  persistence  function. 

4.  The  COA  Sketch  tasks  are  persisted. 

5.  The  full  list  of  tasks  is  loaded. 

6.  The  list  is  concatenated  into  a  three  separate  lists  for  specified,  implied  and 
essential  and  stored  in  the  corresponding  plan  object.  Type  determines  if  a  task  is 
set  as  a  specified  or  implied  task.  If  a  task  is  essential  determines  if  it  is  added  to 
the  essential  list. 

7.  Changes  are  sent  to  IWPC. 

Use  Case  17.25:  Persist  COA  Elements 

User  Story:  User  added,  updated  and  deletes  COA  elements  from  a  plan  loaded  from 
IWPC. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

21.  IWPC  is  functional 

22.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  COA  Sketch  specific  data  will  be  removed  when  an  element  is  deleted. 
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•  Causal  Links  between  IWPC  and  COA  Sketch  elements  are  store  in  COA  Sketch 
persisted  store. 

Main  Success  Scenario: 

1 .  New  COA  elements  of  a  matching  IWPC  type  will  be  added  to  the  IWPC  plan. 

2.  New  COA  elements  of  a  matching  IWPC  type  store  COA  Sketch  specific  data  in 
the  COA  Sketch  persisted  store. 

3.  COA  elements  that  are  updated  will  have  new  values  set. 

4.  Deleted  COA  elements  are  removed  from  the  IWPC  plan. 

5.  Deleted  COA  elements  also  remove  COA  Sketch  specific  data  from  the  COA 
Sketch  persisted  store. 

6.  Deleted  causal  links  change  parent  id  to  the  IWPC  plan  element  id. 

7.  Added  causal  links  change  the  parent  id  to  the  id  of  the  new  parent  id  in  the  plan 
object. 

Use  Case  17.26:  Rename  IWPC  Plan 

User  Story:  User  renames  COA  that  was  loaded  from  IWPC  and  the  system  needs  to 
make  sure  a  unique  name  is  passed  to  IWPC  on  persist  action. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

23.  IWPC  is  functional 

24.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  The  start  of  the  IWPC  plan  name  will  be  what  the  user  entered. 

Main  Success  Scenario: 

1 .  User  enters  a  new  name  for  a  COA  that  was  loaded  from  IWPC. 

2.  User  persists  the  changes. 

3.  The  new  name  is  validates  as  unique. 

4.  If  the  name  is  not  unique,  an  incremental  number  is  appended  to  the  end  of  the 
name.  The  number  is  incremented  until  a  unique  name  is  created. 

5.  The  name  of  the  plan  is  changed  to  the  new  name,  approved  by  the  system. 

Use  Case  17.27:  IWPC  Effect  Timing 

User  Story:  When  persisting  the  d-day  offset  and  duration  of  an  effect  to  IWPC  the 
smallest  unit  of  time  that  can  be  used  is  days.  COA  Sketch  can  store  time  in 
milliseconds,  so  lose  of  precision  is  inevitable.  The  start  time  is  moved  to  the  beginning 
of  the  day  it  occurs  and  the  end  time  is  moved  to  the  end  of  the  day  it  occurs.  From  there 
the  duration  of  the  effect  is  calculated  and  the  d-day  offset  is  set  based  on  the  updated 
start  time. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
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Preconditions: 

25.  IWPC  is  functional 

26.  COA  Sketch  is  configured  with  IWPC  conneetion  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  Duration  will  be  caleulated  based  on  the  day  an  effeet  starts  and  the  day  it  ends. 
Main  Success  Scenario: 

1 .  An  effect  has  a  change  in  its  start  of  stop  time. 

2.  If  start  time  is  after  midnight  then  time  is  adjusted  to  midnight  (start  of  the  day). 

3.  If  end  time  is  before  midnight  then  time  is  adjusted  to  midnight  (start  of  next  day). 

4.  Number  of  days  between  new  start  and  new  stop  is  caleulated. 

5.  D-Day  offset  is  found  using  the  new  start  date. 

6.  D-Day  offset  and  duration  are  persisted  to  IWPC. 


D-31 


IWPC  Interaction  User  Level  Use  Cases 


Use  Case  Y.1:  Team  Member  Imports  IWPC  Plan  Into  CO  A  Sketch 

User  Story:  While  using  COA  Sketch,  the  user  might  want  to  view  a  plan  created  in 
IWPC.  This  plan  can  be  loaded  and  displayed  as  if  it  were  a  plan  originating  from  COA 
Sketch. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Support  Actors:  COA  Sketch,  IWPC 
Preconditions: 

1 .  IWPC  is  functional 

2.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  User  decides  to  view  IWPC  plan  in  COA  Sketch. 

Guarantees: 

•  IWPC  plan  data  will  not  stored  in  two  places. 

•  Tasks  can  no  longer  be  distinguished  as  Essential. 

Main  Success  Scenario: 

1.  User  activates  the  import  function. 

2.  A  list  of  IWPC  plans  is  presented  to  the  user. 

3.  The  user  selects  a  plan  to  import. 

4.  The  system  determines  the  plan  has  not  been  previously  imported  and  saved  so  a 
new  project  is  created  and  displayed  containing  the  IWPC  plan  data 

Alternative  1:  Plan  has  been  previously  imported 

4.  The  system  determines  the  plan  has  been  previously  imported  so  it  finds  and 
displays  the  existing  project. 

Alternative  2:  Can  Not  Establish  Connection  with  IWPC 

1 .  User  activates  the  import  function 

2.  The  system  indicates  a  connection  to  IWPC  could  not  be  made,  no  import  is 
performed. 

Alternative  3:  Import  plan  into  existing  Project? 

1 .  User  indicates  they  wish  to  import  an  IWPC  plan  into  an  existing  project 

2.  ? 


Use  Case  Y.2:  Team  Member  Opens  COA  Sketch  Project  Containing 
an  IWPC  plan 

User  Story:  User  wants  to  view  a  saved  project  in  the  COA  Sketch  client. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Support  Actors:  COA  Sketch,  IWPC 
Preconditions: 
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1 .  IWPC  is  functional 

2.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  User  decides  to  view  a  COA  Sketch  project. 

Guarantees: 

•  If  there  are  multiple  IWPC  plans,  their  Mission  Statements  will  be  concatenated 
to  form  one  project  Mission  Statement. 

Main  Success  Scenario: 

1 .  The  user  activates  the  open  function. 

2.  The  system  displays  the  list  of  projects. 

3.  The  user  selects  a  project  to  open. 

4.  The  system  displays  the  project,  if  a  COA  is  from  IWPC,  the  plan  data  is  loaded 
from  there. 

5.  The  system  sets  the  project  phases  to  that  of  the  plan  from  IWPC 
Alternative  1:  Multiple  IWPC  Plans  in  the  project 

5.  The  system  displays  the  list  of  plan  phases  in  the  project. 

6.  The  user  selects  which  phase  they  wish  to  use  for  the  project. 

7.  The  system  sets  the  project  to  the  selected  phase 
Alternative  2:  Can  Not  Establish  Connection  with  IWPC 

4.  The  system  alerts  the  user  that  a  connection  to  IWPC  could  not  be  made,  and 
informs  which  CO  As  will  not  be  loaded 

5.  The  system  loads  the  rest  of  the  project 

6.  The  system  sets  the  project  phase  to  the  default? 

Use  Case  Y.3:  Team  Member  Exports  COA  to  IWPC  as  a  New  Plan 

User  Story:  The  user  wants  to  share  a  COA  that  has  been  created  in  COA  Sketch  with 
the  users  of  IWPC. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Support  Actors:  COA  Sketch,  IWPC 
Preconditions: 

1 .  IWPC  is  functional 

2.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  The  COA  Sketch  COA  is  ready  to  be  viewed  by  the  users  of  IWPC. 

Guarantees: 

•  Data  that  can  be  stored  in  IWPC  will  be  removed  from  COA  Sketch  persistent 
store. 

•  Data  stored  in  COA  Sketch  can  be  mapped  to  IWPC  objects. 

•  A  plan  can  be  exported  to  IWPC  only  once. 

Main  Success  Scenario: 

16.  The  user  activates  the  export  function. 

17.  The  system  displays  a  list  of  COAs  that  are  not  empty,  and  have  not  been 
previously  exported. 

18.  The  user  selects  the  COA  to  export. 
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19.  The  system  sends  the  data  to  IWPC  and  deletes  it  from  the  COA  Sketch  persistent 
store 

20.  IWPC  creates  a  plan  from  the  COA,  project,  and  phase  data. 

i.  Assumptions  are  concatenated  into  a  single  assumption  and  set  in  the  new 
plan.  They  also  remain  in  the  COA  Sketch  persisted  store. 

ii.  Facts  are  concatenated  into  a  single  fact  and  set  in  the  new  plan.  They  also 
remain  in  the  COA  Sketch  persisted  store. 

iii.  Tasks  are  concatenated  into  specified,  implied  and  essential  tasks  and  set 
in  the  new  plan.  They  also  remain  in  the  COA  Sketch  persisted  store. 

iv.  Timing  elements  are  rounded  to  whole  day  increments.  The  start  time  is 
moved  to  the  beginning  of  the  day  it  occurs  and  the  end  time  is  moved  to 
the  end  of  the  day  it  occurs.  From  there  the  duration  of  the  effect  is 
calculated  and  the  D-day  offset  is  set  based  on  the  updated  start  time. 

V.  The  project  mission  statement  is  stored  in  the  IWPC  plan. 

2.  The  system  ensures  the  name  is  unique. 

3.  IWPC  saves  the  plan  as  the  COA  name 

4.  The  system  links  the  project  to  the  IWPC  plan. 

Alternative  1  Name  Already  Exists,  Accept  increment 

21.  The  system  determines  the  name  already  exists  in  IWPC  and  appends  an 
incremental  number  to  the  name  until  a  unique  name  is  created  and  displayed  to 
the  user  for  approval. 

22.  The  user  accepts  the  name 

23.  IWPC  saves  the  plan  as  the  name 

24.  The  system  links  the  project  to  the  IWPC  plan 
Alternative  2:  Name  Already  Exists,  Write  New  One 

6.  The  system  determines  the  name  already  exists  and  appends  an  incremental 
number  to  the  name  until  a  unique  name  is  created  and  displayed  to  the  user  for 
approval. 

7.  The  user  enters  in  a  new  name 

8.  Repeat  to  step  6  in  Main  Success  Scenario 
Alternative  3:  Can  Not  Export  to  IWPC 

9.  The  system  could  not  export  the  data,  for  example  the  connection  to  IWPC  could 
not  be  established. 

10.  The  system  informs  the  user  the  export  failed 

1 1 .  The  COA  remains  in  the  COA  Sketch  persisted  data  store. 


Use  Case  Y.4:  Team  Member  Edits  COA  Sketch  Project  Containing  an 
iWPC  pian 

User  Story:  User  wants  to  edit  a  saved  project  in  the  COA  Sketch  client. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Support  Actors:  COA  Sketch,  IWPC 
Preconditions: 

1 .  IWPC  is  functional 
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2.  COA  Sketch  is  configured  with  IWPC  connection  details. 

3.  A  project  containing  IWPC  plan(s)  is  open 
Triggers:  User  decides  to  edit  a  COA  Sketch  project. 

Guarantees: 

•  Plan  data  will  be  saved  as  it  is  edited. 

Main  Success  Scenario: 

1 .  The  user  enters  the  data  area  he  wants  to  edit 

2.  The  system  locks  the  data  in  that  area 

3.  The  user  edits  data  in  the  plan. 

4.  The  system  sends  the  data  to  IWPC  when  the  user  is  done  editing  the  data. 

5.  IWPC  saves  the  data. 

6.  The  system  unlocks  the  data. 

Alternative  1:  Mission  Statement  Edited 

1 .  The  user  enters  the  mission  statement  editing  area. 

2.  The  system  locks  the  mission  statement  data 

3.  The  user  edits  the  mission  statement  of  the  project. 

4.  The  system  sends  the  mission  statement  for  each  exported  COA  to  IWPC  when 
the  user  is  done  editing  the  mission  statement. 

5.  IWPC  saves  the  data  in  each  plan. 

6.  The  system  unlocks  the  data. 

Alternative  2:  Phase  Data  Edited 

1 .  The  user  enters  the  phase  data  editing  area. 

2.  The  system  locks  the  phase  data. 

3.  User  edits  the  phase  data  in  the  project. 

4.  The  system  sends  the  new  phase  data  for  each  exported  COA  to  IWPC  when  the 
user  is  done  editing  the  phase  data. 

5.  IWPC  saves  the  data  in  each  plan. 

6.  The  system  unlocks  the  data. 

Alternative  3:  Task/ Assumption/Fact  Data  Edited 

1 .  The  user  enters  the  task/assumption/fact  editing  area. 

2.  The  system  locks  the  specific  data. 

3.  The  user  edits  the  task/assumption/fact  for  a  plan. 

4.  The  system  sends  the  updated  task/assumption/fact  text  to  IWPC  when  the  user  is 
done  editing  the  data. 

5.  IWPC  updates  the  task/assumption/fact  in  the  correct  plan. 

6.  The  system  updates  the  task/assumption/fact  in  persistent  data  storage. 

7.  The  system  unlocks  the  data. 

Alternative  3:  New  Task/ Assumption/Fact  Added 

1 .  The  user  enters  a  new  task/assumption/fact. 

2.  The  system  locks  the  specific  data. 

3.  The  user  edits  the  task/assumption/fact  for  a  plan. 

4.  The  system  sends  the  new  task/assumption/fact  text  to  IWPC  when  the  user  is 
done  editing  the  data. 

5.  IWPC  adds  (concatenates)  the  new  task/assumption/fact  to  every  exported  plan 

6.  The  system  adds  the  new  task/assumption/fact  to  persistent  data  storage. 

7.  The  system  unlocks  the  data 
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Alternative  4:  IWPC  Concatenated  Task/ Assumption/F act  Removed 

1 .  The  user  deletes  a  IWPC  generated  task/assumption/fact. 

2.  The  system  locks  the  specific  data. 

3.  The  system  rebuilds  the  concatenated  task/assumption/fact  from  the  existing  CO  A 
Sketch  tasks/assumptions/facts.  If  there  aren’t  any,  no  new  object  is  created. 

4.  IWPC  updates  the  task/assumption  fact  for  the  plan. 

5.  The  system  unlocks  the  data 
Alternative  4:  Task/ Assumption/Fact  Removed 

1 .  The  user  deletes  a  task/assumption/fact. 

2.  The  system  locks  the  specific  data. 

3.  The  system  removes  the  task/assumption/fact  from  persistent  data  storage. 

4.  IWPC  does  not  remove  the  task/assumption/fact  from  its  concatenated  list. 

5.  The  system  unlocks  the  data 


Use  Case  Y.5:  Rename  IWPC  Plan 

User  Story:  User  renames  a  COA  that  was  loaded  from  IWPC. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

1 .  IWPC  is  functional 

2.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  The  start  of  the  IWPC  plan  name  will  be  what  the  user  entered. 

•  The  IWPC  plan  name  will  be  unique 

Main  Success  Scenario: 

1 .  The  user  enters  a  new  name  for  a  COA  that  was  loaded  from  IWPC. 

2.  The  user  completes  setting  the  name. 

3.  The  system  validates  the  new  name  as  unique. 

4.  IWPC  renames  the  plan  to  the  new  name. 

5.  The  system  updates  links  from  the  project  to  the  new  name. 

Alternative  1:  Name  Already  Exists,  Accept  increment 

3.  The  system  determines  the  name  already  exists  and  appends  an  incremental 
number  to  the  name  until  a  unique  name  is  created  and  displayed  to  the  user  for 
approval. 

4.  The  user  accepts  name 

5.  IWPC  renames  the  plan  to  the  new  name. 

6.  The  system  updates  links  from  the  project  to  the  new  name. 

Alternative  2:  Name  Already  Exists,  Write  New  One 

3.  The  system  determines  the  name  already  exists  and  appends  an  incremental 
number  to  the  name  until  a  unique  name  is  created  and  displayed  to  the  user  for 
approval. 

4.  The  user  enters  in  a  new  name 

5.  Repeat  to  step  3  in  Main  Success  Scenario 
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Alternative  3:  Can  Not  Save  to  IWPC 

3.  The  system  could  not  save  the  data,  for  example  the  connection  to  IWPC  could 
not  be  established. 

4.  The  system  informs  the  user  the  rename  failed 

5.  The  system  keeps  the  plan  with  the  original  name. 

System  Use  Cases  from  Prototype 

Import  IWPC  Plan  Into  COA  Sketch 

User  Story:  While  using  COA  Sketch  the  user  might  want  to  view  a  plan  inside  of 
IWPC.  This  plan  can  be  loaded  and  displayed  as  if  it  were  a  plan  originating  from  COA 
Sketch. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Support  Actors:  COA  Sketch,  IWPC 
Preconditions: 

3.  IWPC  is  functional 

4.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  User  decides  to  view  IWPC  plan  in  COA  Sketch. 

Guarantees: 

•  IWPC  plan  will  not  be  altered  until  save  is  applied. 

Main  Success  Scenario: 

5.  User  activates  the  import  function. 

6.  A  list  of  IWPC  plans  is  presented  to  the  user. 

7.  The  user  selects  that  plan  to  import. 

8.  The  system  determines  if  the  plan  is  been  previously  import  and  saved. 

9.  If  plan  has  not  been  import,  the  plan  data  is  loaded  from  IWPC. 

10.  COA  Sketch  plan  process  data  is  created  using  the  IWPC  plan  data. 

Alternative  1: 

5.  If  plan  has  been  import,  the  COA  Sketch  plan  process  is  found. 

6.  The  plan  process  is  then  loaded,  pulling  required  data  from  IWPC. 

Finish: 

1 1 .  The  plan  process  data  is  returned  to  the  client. 

12.  The  plan  process  data  is  parsed  and  data  objects  are  created. 

13.  Objects  with  COA  Sketch  specific  data  are  marked  as  new  objects. 


Open  COA  Sketch  Plan  Process 

User  Story:  User  wants  to  view  a  persisted  plan  in  the  COA  Sketch  client. 

Scope:  User  to  COA  Sketch  Interaction 

Level:  User  Goal 

Primary  Actor:  Team  Member 

Support  Actors:  COA  Sketch,  IWPC 

Preconditions: 
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5.  IWPC  is  functional 

6.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  User  decides  to  view  a  COA  Sketch  plan  process. 

Guarantees: 

•  No  plan  data  will  be  altered  until  save  is  applied. 

Main  Success  Scenario: 

6.  User  activates  the  open  function. 

7.  A  list  of  plan  process  is  presented  to  the  user. 

8.  The  user  selects  the  plan  process  to  open. 

9.  When  COAs  are  being  loaded  they  system  checks  if  it  is  an  IWPC  plan. 

10.  If  the  COA  is  from  IWPC,  the  plan  data  is  loaded  from  there. 

1 1 .  If  the  COA  is  not  from  IWPC,  the  COA  data  is  loaded  from  the  COA  Sketch 
persistent  store. 

12.  The  plan  process  data  is  returned  to  the  client. 

13.  The  plan  process  data  is  parsed  and  data  objects  are  created. 

14.  Objects  are  marked  as  not  new. 

15.  Phase  data  is  selected  by  the  system. 

16.  Skip  to  step  12. 

Alternative  1: 

10.  If  multiple  Phase  set  are  available  a  list  if  presented  to  the  user. 

1 1 .  The  user  selects  the  Phase  set  to  use. 

Finish: 

12.  The  phase  data  is  set  for  the  plan  process. 


Export  COA  to  IWPC  as  a  New  Plan 

User  Story:  The  user  wants  to  share  a  COA  that  has  been  created  with  the  users  of 
IWPC. 

Scope:  User  to  COA  Sketch  Interaction 
Level:  User  Goal 
Primary  Actor:  Team  Member 
Support  Actors:  COA  Sketch,  IWPC 
Preconditions: 

7.  IWPC  is  functional 

8.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  The  COA  Sketch  COA  is  ready  to  be  viewed  by  the  users  of  IWPC. 

Guarantees: 

•  Data  that  can  be  stored  in  IWPC  will  be  removed  from  COA  Sketch  persistent 
store. 

•  Data  stored  in  COA  Sketch  can  be  mapped  to  IWPC  objects. 

Main  Success  Scenario: 

25.  The  user  activates  the  export  function. 

26.  The  system  determines  which  COAs  can  be  exported. 

27.  A  list  of  exportable  plans  is  displayed  to  the  user. 

28.  The  user  selects  the  COA  to  export. 

29.  Basic  export  data  and  phases  are  sent  to  the  service. 
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30.  The  plan  process  data  for  the  COA  is  loaded. 

3 1 .  A  new  IWPC  plan  is  created  from  the  COA,  plan  process  and  phase  data. 

32.  When  the  COA  data  is  added  to  the  new  IWPC  plan,  its  non  COA  Sketch  specific 
data  is  removed  from  the  COA  Sketch  persisted  store. 

33.  When  the  phase  data  is  added  to  the  new  IWPC  plan,  the  related  plan  process 
phase  data  is  removed  from  COA  Sketch  persisted  store. 

34.  When  the  COA  element  data  is  added  to  the  new  IWPC  plan,  its  non  COA  Sketch 
specific  data,  can  causal  links  are  removed  from  the  COA  Sketch  persisted  store. 

35.  Assumptions  are  concatenated  into  a  single  assumption  and  set  in  the  new  plan. 

36.  Facts  are  concatenated  into  a  single  fact  and  set  in  the  new  plan. 

37.  Tasks  are  concatenated  into  specified,  implied  and  essential  tasks  and  set  in  the 
new  plan. 

38.  The  name  is  validated. 

39.  If  the  name  is  already  used  an  incremental  number  is  appended  to  the  name  until  a 
unique  name  is  created. 

40.  The  new  plan  is  sent  to  IWPC  for  persisting. 


Load  Mission  Statement  from  IWPC 

User  Story:  When  plan(s)  are  loaded  from  IWPC  a  mission  statement  must  be  defined 
for  the  plan  process.  The  statement  will  be  a  concatenation  of  all  unique  statements  from 
each  plan. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

9.  IWPC  is  functional 

10.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  Each  individual  mission  statement  will  not  be  altered  during  concatenation 
process. 

Main  Success  Scenario: 

6.  All  IWPC  plans  are  loaded. 

7.  A  list  of  unique  mission  statements  is  created  from  the  mission  statements  from 
each  plan. 

8.  One  big  mission  statement  is  created  by  concatenating  each  unique  statement 
together. 

9.  The  big  mission  statement  is  set  for  the  plan  process  being  returned  to  the  client. 


Persist  Mission  Statement  to  IWPC 

User  Story:  When  the  user  persists  the  plan,  the  mission  statement  must  be  stored  be  to 
IWPC. 

Scope:  COA  Sketch  plan  service 
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Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

1 1 .  IWPC  is  functional 

12.  COA  Sketch  is  configured  with  IWPC  connection  details. 
Triggers:  Plan  process  has  been  persisted. 

Guarantees: 

•  Mission  statement  will  be  stored  back  to  IWPC. 

Main  Success  Scenario: 

6.  Plan  data  loaded  from  IWPC. 

7.  Mission  statement  data  is  received. 

8.  Mission  statement  is  marked  as  changed.  If  not  changed  then  stop. 

9.  If  changed  set  mission  statement  in  each  plan  object. 

10.  Send  plan  changes  back  to  IWPC. 


Persist  Phase  Changes  to  IWPC 

User  Story:  Phases  have  changed  and  the  plan(s)  in  IWPC  need  to  be  updated  with  the 
changes. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

13.  IWPC  is  functional 

14.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Phases  have  changed  when  persisted. 

Guarantees: 

•  Phase  data  is  stored  to  IWPC. 

Main  Success  Scenario: 

9.  Plan  data  is  loaded  from  IWPC. 

10.  Phase  changes  are  extracted  from  the  persistence  data. 

11.  The  original  phase  objects  are  found. 

12.  Deleted  phase  are  removed  from  the  original  set. 

13.  Phases  are  updated  in  the  original  set. 

14.  New  phases  are  added  to  the  original  set. 

15.  For  each  plan,  the  phases  are  updated  to  match  the  updated  set  previously  created. 

16.  The  plan  updates  for  each  will  be  sent  back  to  IWPC. 


Load  Assumptions  for  IWPC  Plan 

User  Story:  Assumptions  need  to  be  loaded  from  an  IWPC  plan  and  made  into  a  COA 
Sketch  object. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
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Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

15.  IWPC  is  functional 

16.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  Assumption  data  is  not  lost  during  loading. 

Main  Success  Scenario: 

5.  Plan  is  loaded  from  IWPC. 

6.  Assumption  data  is  pulled  from  the  plan. 

7.  RTF  meta  data  is  cleaned  off 

8.  If  assumption  is  not  an  empty  string,  create  new  assumption  for  COA  Sketch. 


Load  Facts  for  IWPC  Plan 

User  Story:  Facts  need  to  be  loaded  from  an  IWPC  plan  and  made  into  a  COA  Sketch 
object. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

17.  IWPC  is  functional 

18.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  Fact  data  is  not  lost  during  loading. 

Main  Success  Scenario: 

5.  Plan  is  loaded  from  IWPC. 

6.  Fact  data  is  pulled  from  the  plan. 

7.  RTF  meta  data  is  cleaned  off. 

8.  If  fact  is  not  an  empty  string,  create  new  fact  for  COA  Sketch. 


Load  Specified  Tasks  for  IWPC  Plan 

User  Story:  Specified  Tasks  need  to  be  loaded  from  an  IWPC  plan  and  made  into  a  COA 
Sketch  object. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

19.  IWPC  is  functional 

20.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 
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Guarantees: 

•  Specified  Task  data  is  not  lost  during  loading. 

Main  Success  Scenario: 

6.  Plan  is  loaded  from  IWPC. 

7.  Specified  Task  data  is  pulled  from  the  plan. 

8.  RTF  meta  data  is  cleaned  off. 

9.  If  specified  task  is  not  an  empty  string,  create  new  task  for  COA  Sketch. 

10.  Essential  tasks  cannot  be  distinguished  and  are  filtered  out. 


Load  Implied  Tasks  for  IWPC  Plan 

User  Story:  Implied  Tasks  need  to  be  loaded  from  an  IWPC  plan  and  made  into  a  COA 
Sketch  object. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

2 1 .  IWPC  is  functional 

22.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  Implied  Task  data  is  not  lost  during  loading. 

Main  Success  Scenario: 

6.  Plan  is  loaded  from  IWPC. 

7.  Implied  Task  data  is  pulled  from  the  plan. 

8.  RTF  meta  data  is  cleaned  off. 

9.  If  Implied  Task  is  not  an  empty  string,  create  new  task  for  COA  Sketch. 

10.  Essential  Tasks  cannot  be  distinguished  and  are  filtered  out. 


Persist  Assumptions  to  IWPC  Plan 

User  Story:  The  user  has  changed  the  assumptions  and  wants  to  persist  them  back  to 
IWPC. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

23.  IWPC  is  functional 

24.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  persisted  back  to  IWPC. 

Guarantees: 

•  Assumption  data  from  other  plans  will  not  be  stored  in  current  plan  being 
persisted. 

Main  Success  Scenario: 
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5.  User  alters  the  assumption  pulled  from  IWPC. 

6.  User  activates  the  persistence  function. 

7.  The  new  value  is  stored  in  the  corresponding  plan  object. 

8.  Changes  are  sent  to  IWPC. 

Alternative  1: 

1 .  User  deletes  the  assumption  pulled  from  IWPC  or  no  assumption  existed  in  plan 
to  begin  with. 

2.  User  creates  new  assumptions  in  COA  Sketch. 

3.  User  activates  the  persistence  function. 

4.  The  COA  Sketch  assumptions  are  persisted. 

5.  The  full  list  of  assumptions  is  loaded. 

6.  The  list  is  concatenated  into  a  single  assumption  and  stored  in  the  corresponding 
plan  object. 

7.  Changes  are  sent  to  IWPC. 


Persist  Facts  to  IWPC  Plan 

User  Story:  The  user  has  changed  the  acts  and  wants  to  persist  them  back  to  IWPC. 

Scope:  COA  Sketch  plan  service 

Level:  System  Goal 

Primary  Actor:  COA  Sketch  System 

Support  Actors:  IWPC 

Preconditions: 

25.  IWPC  is  functional 

26.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  persisted  back  to  IWPC. 

Guarantees: 

•  fact  data  from  other  plans  will  not  be  stored  in  current  plan  being  persisted. 
Main  Success  Scenario: 

5.  User  alters  the  fact  pulled  from  IWPC. 

6.  User  activates  the  persistence  function. 

7.  The  new  value  is  stored  in  the  corresponding  plan  object. 

8.  Changes  are  sent  to  IWPC. 

Alternative  1: 

1 .  User  deletes  the  fact  pulled  from  IWPC  or  no  fact  existed  in  plan  to  begin  with. 

2.  User  creates  new  facts  in  COA  Sketch. 

3.  User  activates  the  persistence  function. 

4.  The  COA  Sketch  acts  are  persisted. 

5.  The  full  list  of  facts  is  loaded. 

6.  The  list  is  concatenated  into  a  single  fact  and  stored  in  the  corresponding  plan 
object. 

7.  Changes  are  sent  to  IWPC. 


Persist  Tasks  to  IWPC  Plan 

User  Story:  The  user  has  changed  the  tasks  and  wants  to  persist  them  back  to  IWPC. 
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Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

27.  IWPC  is  functional 

28.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  persisted  back  to  IWPC. 

Guarantees: 

•  Task  data  from  other  plans  will  not  be  stored  in  current  plan  being  persisted. 

Main  Success  Scenario: 

5.  User  alters  the  specified  or  implied  task  pulled  from  IWPC. 

6.  User  activates  the  persistence  function. 

7.  The  new  value  is  stored  in  the  corresponding  plan  object. 

8.  Changes  are  sent  to  IWPC. 

Alternative  1: 

1 .  User  deletes  the  specified  or  implied  task  pulled  from  IWPC  or  no  task  existed  in 
plan  to  begin  with. 

2.  User  creates  new  tasks  in  COA  Sketch. 

3.  User  activates  the  persistence  function. 

4.  The  COA  Sketch  tasks  are  persisted. 

5.  The  full  list  of  tasks  is  loaded. 

6.  The  list  is  concatenated  into  a  three  separate  lists  for  specified,  implied  and 
essential  and  stored  in  the  corresponding  plan  object.  Type  determines  if  a  task  is 
set  as  a  specified  or  implied  task.  If  a  task  is  essential  determines  if  it  is  added  to 
the  essential  list. 

7.  Changes  are  sent  to  IWPC. 


Persist  COA  Elements 

User  Story:  User  added,  updated  and  deletes  COA  elements  from  a  plan  loaded  from 
IWPC. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

29.  IWPC  is  functional 

30.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  COA  Sketch  specific  data  will  be  removed  when  an  element  is  deleted. 

•  Causal  Links  between  IWPC  and  COA  Sketch  elements  are  store  in  COA  Sketch 
persisted  store. 

Main  Success  Scenario: 

8.  New  COA  elements  of  a  matching  IWPC  type  will  be  added  to  the  IWPC  plan. 
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9.  New  COA  elements  of  a  matching  IWPC  type  store  COA  Sketch  specific  data  in 
the  COA  Sketch  persisted  store. 

10.  COA  elements  that  are  updated  will  have  new  values  set. 

1 1 .  Deleted  COA  elements  are  removed  from  the  IWPC  plan. 

12.  Deleted  COA  elements  also  remove  COA  Sketch  specific  data  from  the  COA 
Sketch  persisted  store. 

13.  Deleted  causal  links  change  parent  id  to  the  IWPC  plan  element  id. 

14.  Added  causal  links  change  the  parent  id  to  the  id  of  the  new  parent  id  in  the  plan 
object. 


Rename  IWPC  Plan 

User  Story:  User  renames  COA  that  was  loaded  from  IWPC  and  the  system  needs  to 
make  sure  a  unique  name  is  passed  to  IWPC  on  persist  action. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

3 1 .  IWPC  is  functional 

32.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  The  start  of  the  IWPC  plan  name  will  be  what  the  user  entered. 

Main  Success  Scenario: 

6.  User  enters  a  new  name  for  a  COA  that  was  loaded  from  IWPC. 

7.  User  persists  the  changes. 

8.  The  new  name  is  validates  as  unique. 

9.  If  the  name  is  not  unique,  an  incremental  number  is  appended  to  the  end  of  the 
name.  The  number  is  incremented  until  a  unique  name  is  created. 

10.  The  name  of  the  plan  is  changed  to  the  new  name,  approved  by  the  system. 


IWPC  Effect  Timing 

User  Story:  When  persisting  the  d-day  offset  and  duration  of  an  effect  to  IWPC  the 
smallest  unit  of  time  that  can  be  used  is  days.  COA  Sketch  can  store  time  in 
milliseconds,  so  lose  of  precision  is  inevitable.  The  start  time  is  moved  to  the  beginning 
of  the  day  it  occurs  and  the  end  time  is  moved  to  the  end  of  the  day  it  occurs.  From  there 
the  duration  of  the  effect  is  calculated  and  the  d-day  offset  is  set  based  on  the  updated 
start  time. 

Scope:  COA  Sketch  plan  service 
Level:  System  Goal 
Primary  Actor:  COA  Sketch  System 
Support  Actors:  IWPC 
Preconditions: 

33.  IWPC  is  functional 
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34.  COA  Sketch  is  configured  with  IWPC  connection  details. 

Triggers:  Plan  is  loaded  from  IWPC. 

Guarantees: 

•  Duration  will  be  calculated  based  on  the  day  an  effect  starts  and  the  day  it  ends. 

Main  Success  Scenario: 

7.  An  effect  has  a  change  in  its  start  of  stop  time. 

8.  If  start  time  is  after  midnight  then  time  is  adjusted  to  midnight  (start  of  the  day). 

9.  If  end  time  is  before  midnight  then  time  is  adjusted  to  midnight  (start  of  next  day). 

10.  Number  of  days  between  new  start  and  new  stop  is  calculated. 

1 1 .  D-Day  offset  is  found  using  the  new  start  date. 

12.  D-Day  offset  and  duration  are  persisted  to  IWPC. 
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External  Interfaces  Requirements 


This  document  is  intended  to  list  all  system  level  requirements  for  WHAT  the  external 
interfaces  system  must  do. 

1.  General 

1.1.  The  system  shall  eonnect  to  3  external  systems. 

1.2.  The  system  shall  allow  for  the  specifieation  of  a  geographic  area  of  interest  (AOI) 

1.3.  Map 

1.3.1.  The  system  shall  display  AOIs  on  a  map 

1.3.2.  The  System  shall  display  Friendly  Operating  Locations  on  a  map. 

1.3.3.  The  system  shall  display  targets  on  a  map 

1 . 3 . 3 . 1 .  Should  there  be  mil  standard  symbols? 

1.4.  Search 

1.4.1.  The  system  shall  allow  for  searching  of  Friendly  Operating  Locations  that  match 
specified  search  criteria  within  in  an  AOI 

1.4.2.  The  system  shall  allow  for  searching  of  Friendly  Units  that  match  specified  search 
criteria  within  an  AOI 

1.4.3.  The  system  shall  allow  for  searching  of  Targets  that  match  specified  search 
criteria  (type,  last  observed  time  range,  etc.)  within  an  AOI. 

1.4.4. 

1.5.  Hide  /  Show 

1.5.1.  The  system  shall  allow  for  limiting  display  of  Targets  within  an  AOI  to  only  those 
that  match  search  criteria. 

1.5.2.  The  system  shall  allow  for  displaying  all  Targets  within  an  AOI. 

1.5.3.  The  system  shall  allow  for  limiting  display  of  Friendly  Operating  Locations 
within  an  AOI  to  only  those  that  match  search  criteria. 

1.5.4.  The  system  shall  allow  an  AOI  and  all  associated  Operating  Locations,  Targets  to 
be  hidden  on  the  map. 

1.5.5.  The  system  shall  allow  an  AOI  and  all  associated  Operating  Locations  and 
Targets  to  be  shown  on  the  map. 

1.5.6.  When  showing  or  hiding  AOIs  the  display  of  Friendly  Operating  Locations  and 
Targets  within  an  AOI  to  that  match  search  criteria  shall  be  maintained. 

1.6.  Layering 

1.6.1.  The  system  shall  allow  for  AOIs  to  be  layered  on  top  of  each  other. 

1 .6.2.  The  system  shall  allow  for  viewing  of  filters  applied  to  an  AOI. 

1.6.3.  The  system  shall  allow  for  the  order  of  the  AOI  layers  to  be  changed. 

1.7.  The  system  shall  allow  information  to  be  displayed  for  selected  Friendly  Operating 
Locations,  Units,  Targets. 

1.8.  Selection 

1.8.1.  The  system  will  allow  for  selection  of  a  Strategy  Object. 

1.8.2.  The  system  shall  allow  for  the  selection  of  a  Center  of  Gravity 

1.8.3.  The  system  shall  allow  for  an  AOI  to  selected 

1.8.4.  Friendly  Operating  Locations 

1 .8.4. 1 . 1 .  The  system  shall  allow  for  all  visible  Operating  Locations  in  an 
AOI  to  be  selected  with  an  AOI. 
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1.8.4. 1.2.  The  system  shall  allow  for  the  selection  of  a  specific  individual 
Operating  Location  within  an  AOI 

1.8.4. 1 .3.  The  system  shall  allow  for  the  selection  of  specific  multiple 
Operating  Locations  within  an  AOI 

1 .8.4. 1 .4.  The  system  shall  allow  for  the  selection  of  specific  multiple 
Operating  Locations  within  an  AOI  that  matches  search  criteria. 

1.8.4.2.  Friendly  Units 

1 .8.4.2. 1 .  The  system  shall  allow  for  the  selection  of  a  specific  individual 
Friendly  Unit  within  an  AOI 

1 .8.4.2. 2.  The  system  shall  allow  for  the  selection  of  specific  multiple 
Friendly  Units  within  an  AOI. 

1 .8.4.2. 3.  The  system  shall  allow  for  the  selection  of  all  Friendly  Units 
within  an  AOI 

1 .8.4.2.4.  The  system  shall  allow  for  the  selection  of  Friendly  Units  that 
match  search  criteria  within  an  AOI. 

1.8.4.3.  Targets 

1 .8.4.3. 1 .  The  system  shall  allow  the  user  to  select  one  or  more  targets. 

1 .8.4. 3. 2.  The  system  shall  allow  for  the  selection  of  all  Targets  within  an 
AOI 

1 .8.4. 3. 3.  The  system  shall  allow  for  the  selection  of  Targets  that  match 
search  criteria  within  an  AOI. 

1.9.  Search  for  Friendly  Operating  Locations  AOI 

1.9.1.  The  system  shall  allow  for  the  search  of  Friendly  Operating  Locations  based  on  a 
specified  geographic  area  AND  any  combination  of  restrictions  including: 

1.9. 1.1.  Time 

1 .9. 1 .2.  Minimum  /  maximum  number  of  runways 

1 .9. 1 .3 .  Mobile  /  stationary  locations 

1 .9. 1 .4.  Whether  the  locations  support  air  operations 

1 .9. 1 .5.  Availability  of  specific  items 

1 .9. 1 .6.  The  presence  of  certain  types  of  friendly  units 

1 .9. 1 .7.  The  country  of  ownership 

1 .9. 1 .8.  The  service  in  charge  of  the  operating  location 

1 .9. 1 .9.  Availability  on  a  specific  date  /  dates 

1.9.2.  The  system  shall  allow  for  the  specification  of  restrictions  to  be  combined  using  a 
Boolean  OR. 

1.9.3.  The  system  shall  allow  for  the  specification  of  restrictions  to  be  combined  using  a 
Boolean  AND. 

1 .9.4.  The  system  shall  allow  for  the  specification  of  restrictions  to  be  negated  using 
NOT  if  appropriate.  (For  example  negating  the  minimum  number  of  runways  may 
not  make  sense.) 

1.10.  Search  for  Friendly  Units 

1.10.1.  The  system  shall  allow  for  the  search  of  Friendly  Units  within  an  AOI  based  on  a 
specified  geographic  area  AND  any  combination  of  restrictions  including: 

1.10.1.1.  Time 

1.10.1.2.  Unit  Type  (Air,  Electronic,  Ground,  etc.) 

1.10.1.3.  Service  (Army,  AF,  etc.) 
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1.10.1.4.  Parent  country 

1.10.1.5.  Ship  type 

1.10.1.6.  Aircraft  type 

1.10.1.7.  Artillery  type 

1.10.2.  The  system  shall  allow  for  the  specification  of  restrictions  to  be  combined  using  a 
Boolean  OR. 

1.10.3.  The  system  shall  allow  for  the  specification  of  restrictions  to  be  combined  using  a 
Boolean  AND. 

1.10.4.  The  system  shall  allow  for  the  specification  of  restrictions  to  be  negated  using 
NOT  if  appropriate.  (For  example  negating  the  time  may  not  make  sense.) 

1.11.  Friendly  Units  able  to  Strike  specified  AOI 

1.11.1.  The  system  shall  allow  for  finding  all  friendly  units  that  are  able  to  strike 
anywhere  within  a  specified  AOI. 

1.11.1.1.  The  system  shall  allow  for  restricting  the  results  of  all  friendly  units  that 
are  able  to  strike  anywhere  within  a  specified  geographic  area  to  the  filter 
criteria. 

1.11.1.1.1.  Time 

1 . 1 1 . 1 . 1 .2.  Unit  Type  (Air,  Electronic,  Ground,  etc.) 

1 . 1 1 . 1 . 1 .3.  Service  (Army,  AF,  etc.) 

1.11.1.1.4.  Parent  country 

1.11.1.1.5.  Ship  type 

1.11.1.1.6.  Aircraft  type 

1.11.1.1.7.  Artillery  type 

1.11.1.2.  The  system  shall  allow  for  the  specification  of  restrictions  to  be  combined 
using  a  Boolean  OR. 

1.1 1.2.  The  system  shall  allow  for  the  specification  of  restrictions  to  be  combined  using  a 
Boolean  AND. 

1.1 1.3.  The  system  shall  allow  for  the  specification  of  restrictions  to  be  negated  using 
NOT  if  appropriate.  (For  example  negating  the  time  may  not  make  sense.) 

1.12.  Target  Association  with  Strategy  Object 

1.12.1.  The  system  shall  allow  for  one  or  more  targets  to  be  associated  with  a  strategy 
object. 

1.12.2.  The  system  shall  allow  for  all  targets  that  match  search  criteria  within  an  AOI  to 
be  associated  with  a  strategy  object. 

1.12.3.  The  system  shall  allow  for  one  or  more  targets  associations  to  be  removed  from  a 
strategy  object. 

1.12.4.  The  system  shall  allow  for  associations  between  strategy  objects  and  targets  to  be 
viewed. 

1.12.5.  The  system  shall  allow  for  the  status  of  each  target  associated  with  a  strategy 
object  to  be  viewed. 

1.12.6.  The  system  shall  allow  the  user  to  view  the  percentage  of  targets  associated  with  a 
strategy  element  that  must  be  engaged  to  produce  desired  effects. 

1.12.7.  The  system  shall  allow  the  user  to  enter/modify  the  percentage  of  targets 
associated  with  a  strategy  element  that  must  be  engaged  to  produce  desired  effects. 

1.12.8.  The  system  shall  allow  the  user  to  view  the  number  of  DMPIs  associated  to 
targets  that  are  associated  to  a  strategy  object. 
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1.12.9.  ?  The  system  shall  be  able  to  pull  the  status  of  targets  in  the  SOR  and  determine  if 
the  Strategy  Object  target  goal  is  being  met  by  scheduled  targeting. 

1.12.10.  ?  The  system  shall  be  able  to  pull  the  status  of  targets  in  the  SOR  and 
determine  if  the  Strategy  Object  target  goal  is  being  met  by  scheduled  resource 
allocation. 

1.12.11.  ?  The  system  shall  be  able  to  pull  the  status  of  targets  in  the  SOR  and 
determine  if  the  Strategy  Object  target  goal  was  met  by  an  operation  (using  BDA). 

1.13.  Target  Association  with  Center  of  Gravity 

1.13.1.  The  system  shall  allow  for  one  or  more  targets  to  be  associated  with  a  Center  of 
Gravity. 

1.13.2.  The  system  shall  allow  for  all  targets  that  match  search  criteria  within  an  AOl  to 
be  associated  with  a  Center  of  Gravity. 

1.13.3.  The  system  shall  allow  for  one  or  more  targets  associations  to  be  removed  from  a 
Center  of  Gravity. 

1.13.4.  The  system  shall  allow  for  associations  between  Center  of  Gravity  and  targets  to 
be  viewed. 

1.13.5. 

2.  Data  Modification 

2.1.  The  system  shall  display  all  data  that  is  inconsistent  with  SOR  data  due  to 
modifications,  additions,  and  deletions. 

2.2.  The  system  shall  indicate  what  data  in  the  COA  is  not  consistent  with  data  maintained 
in  available  SORs. 

2.3.  The  system  shall  allow  Friendly  Operating  Locations  to  be  created  in  the  COA. 

2.4.  The  system  shall  allow  Friendly  Operating  Locations  to  be  modified  in  the  COA. 

2.5.  The  system  shall  allow  Friendly  Operating  Locations  to  be  deleted  from  the  COA. 

2.6.  The  system  shall  relate  Friendly  Operating  Location  data  that  was  imported  back  to 

the  SOR  it  originated  from. 

2.7.  The  system  shall  maintain  SOR  information  for  Friendly  Operating  Locations  even  if 
the  user  has  overridden  the  SOR  data. 

2.8.  The  maintained  SOR  data  shall  continue  to  be  updated  from  the  SOR  even  if  the  user 
overridden  the  SOR  data  for  the  COA. 

2.9.  The  system  shall  allow  all  Friendly  Operating  Location  modifications  to  be  reverted 
back  to  using  SOR  data  rather  than  user  specified  data. 

2.10.  The  system  shall  allow  all  Friendly  Operating  Location  deletions  to  be  restored  using 
SOR  data  if  the  FOL  was  linked  to  a  SOR  (rather  than  user  specified  data). 

2.11.  The  system  shall  allow  for  viewing  of  differences  between  SOR  data  and  user 
modifications  to  the  data. 

2.12.  The  system  shall  allow  modifications  to  specified  (selected  or  all)  Friendly  Operating 
Locations  to  be  exported  so  external  tools  can  be  used  to  import  the  modifications  back 
into  the  SOR. 

2.13.  The  system  may  allow  specified  Friendly  Operating  Locations  additions  to  be 
exported. 

2.14.  The  system  may  allow  specified  Friendly  Operating  Location  deletions  to  be 
exported. 

2. 1 5.  The  system  may  allow  Friendly  Units  to  be  added  to  a  Friendly  Operating  Location  in 
the  COA. 
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2.16.  The  system  shall  allow  Friendly  Units  to  be  modified  in  the  COA. 

2. 17.  The  system  shall  allow  Friendly  Units  to  be  deleted  from  the  COA. 

2.18.  The  system  shall  allow  modifieations  to  specified  Friendly  Units  to  be  exported. 

2. 19.  The  system  shall  allow  specified  Friendly  Unit  additions  to  be  exported. 

2.20.  The  system  shall  allow  specified  Friendly  Unit  deletions  to  be  exported. 

2.2 1 .  The  system  shall  allow  all  Friendly  Unit  modifications  to  be  reverted  back  to  using 
SOR  data  rather  than  user  specified  data. 

2.22.  The  system  shall  allow  all  Friendly  Unit  deletions  to  be  restored  using  SOR  data 
(rather  than  user  specified  data). 

2.23.  The  system  shall  allow  for  (selected)  targets  to  be  removed  from  the  COA. 

2.24.  The  system  shall  allow  for  targets  to  be  added  to  the  COA. 

2.25.  The  system  shall  allow  for  targets  to  be  modified  in  the  COA. 

2.26.  The  system  shall  allow  all  target  modifications  to  be  reverted  back  to  using  SOR  data 
rather  than  user  specified  data. 

2.27.  The  system  shall  allow  all  target  deletions  to  be  restored  using  SOR  data  rather  than 
user  specified  data. 

3.  SOR  Interface  (TO  BE  COMPLETED) 

3.1.  What  are  the  pieces  of  data  we  are  required  to  retrieve  /  modify  /  delete  /  add  for  each 
SOR? 

3.2.  The  system  shall  automatically  update,  in  near  real  time,  all  data  that  is  associated 
with  a  SOR  when  the  SOR  is  updated.  If  the  data  has  been  manually  changed  after 
importing  from  a  SOR,  the  manual  changes  will  not  be  updated. 

3.3.  The  system  shall  retrieve  /  modify  /  delete  /  export  target  data  including 

3.3.1.  Type 

3.3.2.  Location 

3.3.3.  DMPI  count 

3.3.4.  ?  Last  seen  date  /  time 

3.4.  The  system  shall  retrieve  /  modify  /  delete  Friendly  Unit  information  including: 

3.5.  The  System  shall  retrieve  /  modify  /  delete  Friendly  Location  information 
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1  INTRODUCTION 


The  Human  Engineering  (HE)  in  the  Air  &  Space  Operations  Center  (AOC)  project  focused  on 
developing  work-centered  strategy  planning  and  operational  assessment  visualization  tools  and 
concepts.  These  efforts  were  designed  to  operate  with  the  envisioned  information,  applications, 
systems,  and  infrastructure  that  will  be  delivered  with  the  AOC  Block  10.2  capabilities.  The 
research  performed  and  understanding  gained  through  the  collective  HE  in  the  AOC  program 
efforts,  have  led  to  the  need  for  a  study  of  both  human-to-human  and  toolset  collaboration  in 
support  of  the  AOC  strategy  and  operational  assessment  teams  and  their  collocated  and 
distributed  collaborators,  e.g.  Intelligence,  Surveillance  &  Reconnaissance  Division  (ISRD), 
reach  back,  and  coalition  partners. 

The  United  States  Air  Force  (USAF)  is  increasingly  using  dynamic  Effects-based  approaches  for 
monitoring,  assessing,  planning  a  nd  executing  military  operations  .  These  approaches  levy  new 
demands  on  personnel  in  the  Air  and  Space  Op  erations  Center  (AOC)  and  in  reach  -back 
organizations.  In-depth  collaboration  requiring  immediate  shared  acces  s  and  m  anipulation  of 
information  about  the  o  perational  environment,  mission  execution  and  assessm  ent  is  necessary 
between  these  personnel  who  are  of  ten  located  in  physically  disp  arate  locations.  T  he  required 
information  to  support  effects-ba  sed  approaches  consists  not  only  of  data,  but  also  of  context. 
Understanding,  updating  and  synchronization  activi  ties  performed,  and  m  onitoring  effects  upon 
this  system  s-of-systems,  requires  a  tailorable  collaboration  environm  ent  -  one  that  supports  a 
natural  collaborative  workflow  between  both  collocated  as  well  as  remote  users  in  support  of 
near  real-time  coordinated  production  of  AOC  work  products. 
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2  BACKGROUND 


The  Net-centric  strategy  of  the  Department  of  Defense  (DoD)  lays  out  goals  of  easier  sharing  of 
semantic  information  that  “Web  2.0”  technologies  readily  support.  This  new  premise  based  on  a 
“need  to  share”  vs.  the  classic  DoD  “need  to  know”  has  led  to  great  advances  in  collaboration 
amongst  soldiers  and  senior  decision  makers.  For  example,  United  States  Strategic  Command’s 
(USSTRATCOM)  commander  has  been  known  to  use  “BLOG”  technology  in  order  to  promote 
understanding  of  his  guidance  and  facilitate  collaboration  with  and  among  his  troops.  These 
collaboration  tools  still  require  knowledge  gathering  and  user  cognition  of  the  data  elements  in 
order  to  establish  proper  knowledge,  and  ultimately,  understanding  in  situational  context. 

The  future  of  strategy  planning  and  assessment  includes  the  need  for  distributed  teams  to 
collaborate  on  a  strategy  plan.  The  majority  of  work  threads  performed  by  Strategy  Planners 
during  COA  analysis  include  manual  methods  of  information  exchange  such  as  found  on 
whiteboards  or  printed  maps.  These  tools  support  stove-piped  functions  that  cannot  be  associated 
electronically  to  elements  of  the  plan  and  therefore  minimize  essential  contextual  relationships 
from  which  true  information  can  be  derived. 

New  collaboration  technologies  must  move  unstructured  data  from  the  selected  human-to-human 
collaboration  environment  into  structured  information  sets  realized  within  Community  of  Interest 
(COI)  specific  supporting  “tools  that  collaborate.”  Two  tools  developed  by  the  HE  in  the  AOC 
program  and  Commander’s  Predictive  Environment,  respectively,  Course  of  Action  (COA) 
Sketch  and  Subject  Matter  Analysis  and  Research  Toolkit  (SMART),  share  unstructured  data 
captured  from  the  human-to-human  collaboration  environment  and  provide  structure, 
augmentation  and  presentation  of  the  data  such  that  users  can  generate  a  shared  or  common 
understanding  from  multiple  perspectives  on  the  data.  These  tools  operate  within  an  extensible 
technology  environment  designed  for  intense  collaboration. 

A  work-centered  collaboration  environment  is  built  on  technologies  which  support  individual 
and  team  work  activities.  Software  tools  operated  within  that  environment  must  have  the  ability 
to  share  information  and  thus  support  user  knowledge  development.  An  investigation  into  the 
leading  collaboration  tools  in  industry  and  government  has  determined  that  none  of  the  major 
players  in  the  COTS  arena,  including  the  designated  (DOD  CIO  MEMORANDUM,  Feb  02, 
2009)  DoD  Enterprise  Collaboration  Services  provided  by  Defense  Information  Systems  Agency 
(DISA)  and  known  as  E-CollabCenter  and  Defense  Connect  Online  are  extensible  enough  for 
use  in  development  of  concepts  put  forth  in  Section  4.  This  finding  shifted  focus  to  the 
Australian  Department  of  Defence,  Defence  Science  and  Technology  Organisation  (DSTO) 
“LiveSpaces”  technology  for  use  as  the  collaboration  tool  framework.  LiveSpaces  is  founded  on 
human-centered  design  principles  and  the  software  is  in  the  process  of  being  placed  in  open 
source  under  the  GNU  Public  License  version  3  (GPLv3).  LiveSpaces  is  mature,  effective  and 
extensible.  While  LiveSpaces  is  not  as  thin  client  based  as  other  offerings,  the  architecture  is 
extensible  and  supports  ubiquitous  design  (early  proof  of  concepts  have  established  and  extended 
the  LiveSpaces  environment). 
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3  METHODS,  ASSUMPTIONS,  AND  PROCEDURESS 


3.1  Collaboration 

Collaboration  through  distributed  work  environments  has  improved  significantly  in  recent  years 
due  to  advances  in  technology  as  well  as  advances  in  understanding  the  associated  cognitive 
requirements  (Warner,  Letsky,  and  Cowen,  2005).  These  advances,  however,  have  not  been  fully 
realized  with  respect  to  the  user  experience  and  the  ability  for  teams  to  effectively  accomplish 
tasks.  Further,  the  internationalization  of  project  teams  has  resulted  in  a  higher  frequency  of 
distributed  work.  The  work  associated  with  these  distributed  teams  sometimes  results  in  what  has 
been  coined  “intense  collaboration.”  Characteristics  of  intense  collaboration  include  parallel 
(simultaneous)  work  activities,  multiple  and  diverse  understandings  of  the  problem  domain,  high 
levels  of  uncertainty  and  products  requiring  inputs  from  multiple  users  (Kumar,  Fenema,  and 
Von  Glinow,  2004). 


3.2  Collaboration  Environments 

The  Australian  DSTO  LiveSpace  technology  framework  is  designed  to  support  human-to-human 
intense  collaboration  in  a  command  and  control  environment,  particularly  within  the  construct  of 
strategy  planning  activities  at  the  beginning  of  an  operation.  DSTO  describes  the  motivation  for 
a  LiveSpace: 

A  LiveSpace  is  a  technology-enhanced  collaboration  space  for  a  team  of people.  The  purpose 
of  a  LiveSpace  is  to  integrate  technologies  that  help  people  work  together:  to  bring  these 
technologies  together  into  a  supporting  system  that  becomes  part  of  the  background,  rather 
than  the  more  common  situation  where  these  technologies  appear  as  a  set  of  disparate, 
idiosyncratic  and  quirky  hardware  gadgets  and  software  applications  (Phillips,  M.,  2008). 

The  LiveSpace  moves  the  emphasis  on  work  from  the  environment  and  associated  technologies 
to  accomplishing  the  task  at  hand.  The  main  technologies  constituting  a  LiveSpace  include  the 
following  elements:  individual  and  shared  workstations,  projector  displays,  smart  whiteboards, 
video  teleconferencing,  video  and  audio  switching,  and  automatic  lighting  control.  The 
LiveSpace  is  built  upon  open  source  software  using  open  development  standards,  and  therefore, 
is  extensible  in  that  new  hardware  and  software  capabilities  can  easily  be  added. 

The  collaboration  environment  can  be  further  enhanced  through  the  introduction  of  strategy 
planning  support  tools  which  go  beyond  the  traditional  notion  of  simply  operating  within  a 
collaboration  framework.  Rather,  the  goal  herein  is  to  also  demonstrate  “tools  that  collaborate.” 
Strategy  planning  team  interactions  and  effectiveness  are  improved  through  the  collaborative 
technologies  afforded  by  LiveSpaces  and  required  at  the  data  level  among  tools  and  the 
environment.  COA  Sketch  and  SMART  are  strategy  planning  support  tools  which  provide 
unique  perspectives  on  shared  data. 
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3.2.1  Defense  Connect  Online  (DCO) 

The  Defense  Connect  Online  (DCO)  approach  to  collaboration  incorporates  Adobe  Connect  and 
Jabber  Chat.  DCO  accommodates  multiple  users  and  multiple  sites  and  is  excellent  for  structured 
presentations.  Collaboration  is  very  much  presenter  focused  with  a  clear  delegation  of  roles.  In 
situations  where  more  than  one  presenter  is  required  or  necessary,  the  presenter  role  must  be 
assigned  and  sequential,  much  like  passing  the  baton.  In  the  DCO  environment,  a  distinction 
exists  between  the  presenter  and  participants. 


Figure  16.  DCO  Presenter-Focused  Collaboration 

“Adobe  Connect  is  a  personal  web  communication  tool  that  enables  you  to  have  real-time, 
online  meetings  whenever  you  want.  It  also  integrates  the  ability  to  share  and  annotate  your 
screen,  conduct  a  phone  conference  and  broadcast  live  video  from  your  web  camera  for 
efficient  and  productive  online  meetings  ”  (DCO  User  Guide) 

The  DCO  collaboration  environment  contains  the  following  features: 

1 .  Camera  and  Voice  Pod 

a.  Transmits  audio  and  video 

2.  Attendee  List 

a.  Shows  who  is  in  the  meeting  room  and  their  role 

3.  Chat  Pod/Jabber 

a.  Send  and  receive  text  messages 

4.  Share  Pod 

a.  Enables  the  presenter  to  display  images  and  presentations 

5.  Poll  Pod 

a.  Allow  for  feedback  from  participants  during  a  meeting 

6.  Whiteboard  Pod 

a.  Lets  participants  draw  together  in  real  time 

7.  File  Share  Pod 

a.  Share  files  among  the  participants 

8.  Participant  Control 

a.  Allows  Presenter  and  Participants  to  have  private  conversations 
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3.2.2  LiveSpaces 

The  LiveSpaces  environment  as  configured  for  the  assessment  custom  extensions  contained  the 
following  features: 

1 .  Camera  Streaming  and  Audio  Chat 

2.  Presence  (User  activity  monitor) 

3.  Jabber  Chat 

4.  Screen  Sharing 

b.  Make  accessible  to  self  another  user’s  screen 

c.  Make  accessible  to  another  user  own  screen 

5.  Electronic  Whiteboard 

6.  File  Sharing  /  Link  Sharing 

d.  Post  and  access  link  for  team  use 

7.  Shared  Clipboard* 

e.  Post  or  pull  down  information  from  a  team  notepad  (text  only) 

8.  Collaborative  Editing* 

f.  Three-tier  team  “document”  space  (Observe,  Propose,  Edit) 

9.  Live  Point/Synergy* 

10.  Image  Management* 

11.  Information  Ticker* 

Items  marked  with  an  asterisk  (*)  are  capabilities  not  found  in  the  DCO  collaboration 
environment.  Further  LiveSpaces  offers  the  ability  to  develop  customizable  “plug-ins”  to  the 
collaboration  environment.  The  Information  Ticker  and  Image  Management  features  were  two 
such  extensions. 

3.2.3  Collaboration  Environment  Decision  Criteria 

Several  collaboration  frameworks  were  evaluated  based  on  the  general  criteria  of  being  able  to 
provide  the  services  necessary  for  a  collaboration  space,  for  example,  dynamic  routing  of  video 
streams,  screen  sharing  and  information  transfer.  The  frameworks  were  also  evaluated  based  on 
extensibility,  i.e.  the  ability  to  modify  or  integrate  capability  modules.  A  final  consideration  was 
the  effort  required  to  integrate  a  strategy  planning  product  such  as  CO  A  Sketch  without  a  major 
code  base  rewrite. 

The  following  collaboration  frameworks  were  evaluated:  Adobe  Acrobat  Connect  (Defense 
Cormect  Online  [DCO]),  Cisco  WebEx,  Microsoft  LiveMeeting,  Skype,  and  LiveSpaces 
(Australian  Department  of  Defence,  DSTO). 

High-level  evaluation  of  the  alternative  packages  suggested  the  following: 

1 .  Adobe  Acrobat  Connect  nice  platform,  but  too  restrictive 

2.  WebEx/WebEx  Connect  poor  documentation  and  doesn’t  fully  meet  requirements 

3.  Microsoft  LiveMeeting:  no  integration  points  available 

4.  Skype:  nice  platform,  but  requires  an  internet  connection 

5.  LiveSpaces:  mature,  extensible  environment 

LiveSpaces  is  an  attempt  to  “support  advanced  meeting  spaces  and  distributed  multi-site 
collaboration."  DSTO  accomplished  this  by  modeling  the  room  as  a  collection  of  entities,  whose 
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attributes  can  be  manipulated.  The  main  component  is  a  compound  object  that  contains  the  room 
model  and  a  publish/subscribe  message  bus  that  is  used  to  efficiently  route  messages  to  the 
clients.  The  integrated  application  would  benefit  from  the  capabilities  of  the  room,  most 
significantly  from  screen  sharing  and  programmatic  video  routing.  The  accessible  API  could 
allow  an  application  to  fully  participate  as  a  ‘member’  of  the  room. 

Successful  employment  of  the  LiveSpaces  environment  for  similar  Strategy  Planning  activities 
by  the  Australian  Defense  Technology  and  Science  Office  (DSTO),  as  well  as  other  assessments 
such  as  the  Intense  Collaboration  Workshop  held  by  the  TTCP  C3I  Technical  Panel  2  and  HUM 
Technical  Panel  11  9-11  September  2008,  show  additional  promise  for  its  use  in  collaborative 
work  product  generation  by  both  co-located  and  distributed  teams.  Use  of  multiple  shared 
displays  for  synchronized  operations  awareness  and  vector  checking  as  well  as  multi-user  editing 
were  anticipated  to  provide  equal  participation  in  work  product  development  from  both  co¬ 
located  and  distributed  locations.  A  key  feature  anticipated  to  provide  ubiquitous  operation  of  the 
environment  was  the  LivePoint  capability. 

For  these  reasons,  the  Australian  DSTO  LiveSpace  collaboration  environment  was  selected  for 
this  assessment.  LiveSpaces  is  a  mature,  effective  and  extensible  solution  and  built  on  a  human- 
centered  design  philosophy. 


3.3  Collaboration  Models  and  Requirements 

A  model  of  collaboration  for  the  work  environment  was  chosen  to  identify  appropriate  metrics 
for  assessing  user  and  team  performance  and  to  focus  the  scenario  for  application  of  those 
metrics.  Several  models  of  team  collaboration  exist.  However,  Warner,  Letsky  and  Cowen’s 
(2005)  model  of  collaboration  was  chosen  since  it  emphasizes  a  macrocognitive  perspective  and 
is  based  on  four  empirically  supported  collaboration  stages: 

1 .  Knowledge  Construction 

2.  Collaborative  Team  Problem  Solving 

3.  Team  Consensus 

4.  Outcome,  Evaluation  and  Revision 

Each  stage  is  further  defined  by  one  or  more  of  the  16  macrocognitive  processes  described  in 
Table  1.  These  processes  account  for  individual  as  well  as  team  activities. 


Table  1  Sixteen  macrocognitive  processes  proposed  by  Warner,  Letsky  and  Cowen  (2005) 


Macro-cognitive 

Process 

Description 

Individual  mental  model 
construction 

Individual  team  members  use  available  information  and 
knowledge  to  develop  their  mental  picture  of  the  problem  situation 

Knowledge 

interoperability 

The  act  of  exchanging  useful,  actionable  knowledge  among  team 
members 

Individual  task 
knowledge  development 

Individual  team  members  ask  for  clarification  of  data  or 
information,  or  respond  to  clarification  requested  by  other  team 
members 
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Team  knowledge 
development 

All  team  members  participate  in  clarifying  information  to  build 
team  knowledge 

Individual  knowledge 
object  development 

Pictures,  icons,  or  standard  text  developed  by  an  individual  team 
member  or  the  whole  team  to  represent  a  standard  meaning 

Individual  visualization 
and  representation  of 
meaning 

Visualizations  are  used  by  individual  team  members  to  transfer 
meaning  to  other  team  members.  Representations  are  methods 
(e.g.  note  pads)  used  by  individual  team  members  to  sort  data  and 
information  into  meaningful  chunks 

Iterative  information 
collection  and  analysis 

Collecting  and  analyzing  information  to  come  up  with  a  solution 
with  no  specific  solution  mentioned 

Team  shared 
understanding 

The  synthesis  of  essential  data,  information  or  knowledge,  held 
collectively  by  some  (complementary  understanding)  and/or  all 
(congruent  understanding)  team  members  working  together  to 
achieve  a  common  task 

Develop,  rationalize  and 
visualize  solution 
alternatives 

Using  knowledge  to  justify  a  solution 

Convergence  of 
individual  mental  models 
to  team  mental  model 

Convincing  other  team  members  to  accept  specific  data, 
information  or  knowledge 

Team  negotiation 

Team  negotiation  of  solution  alternatives  ending  in  a  final  solution 
option 

Team  pattern  recognition 

The  team  as  a  whole  identifies  a  pattern  of  data,  information  or 
knowledge 

Critical  thinking 

The  team  works  together  toward  a  common  goal,  whereby  goal 
accomplishment  requires  an  active  exchange  of  ideas,  self- 
regulatory  judgment,  and  systematic  consideration  of  evidence, 
counterevidence  and  context  in  an  environment  where  judgments 
are  made  under  uncertainty,  limited  knowledge  and  time 
constraints 

Shared  hidden 
knowledge 

Individual  team  members  share  their  knowledge  through 
prompting  by  other  team  members 

Compare  problem 
solution  against  goals 

Team  members  discuss  solution  option  against  the  goal 

Analyze  and  revise 
solution  options 

Team  members  analyze  final  solution  options  and  revise  them  if 
necessary 

The  16  macrocognitive  processes  can  be  used  to  identify  specific  steps  in  collaboration  which  are 
directly  supported  through  t  ools  and  technologies.  Unders  landing  how  well  m  acrocognitive 
processes  are  supported  within  the  collaborati  on  environment  provides  a  m  cans  of  assessing 
individual  and  team  collaboration  effectiveness.  Expected  m  aero-cognitive  processes  based  on 
event  triggers  in  the  Pacifica  scenario  will  be  compared  to  observed  processes. 

For  instance,  within  the  construct  of  a  strategy  planning  scenario,  individuals  develop  sections  of 
the  Mission  Analysis  independently  and  reconven  e  with  other  team  members  to  build  the  “big 
picture.”  In  this  situa  tion,  understanding  “Individual  Mental  Model  Construction”  focuses  of  an 
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individual’s  ability  to  create  a  knowledge  strueture  of  the  system  or  environm  ent  whieh  affects 
his/her  aetivities  during  Mission  An  alysis.  “Convergence  of  Individu  al  Mental  Models  to  Team 
Mental  Model”  f  oeuses  on  the  team  ’s  ability  to  bring  tog  ether  those  individual’s  work  into  a 
coherent  whole  from  which  the  team  then  works. 


3.4  Collaboration  Effectiveness  Assessment 

For  the  purposes  of  assessing  the  project’s  hypothesis, 

“The  collaboration  environment  enables  a  distributed  strategy  plans  session  which  is  as 
effective  as  that  developed  by  collocated  planners,  ” 

two  questions  must  be  answered.  First,  how  well  did  the  collaboration  technology,  i.e. 
LiveSpaces  environment,  support  individual  and  team  strategy  planner  work?  Seeond,  how  well 
did  the  software  tools  support  strategy  planner  work  (assuming  these  tools  “collaborate”)? 

Understanding  how  well  the  macro-eognitive  proeesses  from  Table  1  are  supported  within  the 
collaboration  environment  provides  a  means  of  assessing  eollaboration  environment 
effeetiveness.  Unfortunately,  measures  of  macrocognition  are  an  emerging  field  of  research,  and 
therefore  not  clearly  defined  or  easily  aecomplished.  To  the  extent  possible,  measurements  were 
conducted  across  the  gamut  of  proposed  maero-cognitive  processes.  Measurements  involved 
defining  work  aetivities,  performing  work,  then  assessing  whether  those  aetivities  were  achieved. 

During  individual  and  team  mental  model  construction,  a  strategy  planner  may  be  required  to 
maintain  awareness  of  the  anticipated  loeation  of  friendly,  adversary  and  unaligned  forees.  The 
planner  ean  be  expected  to  track  information  from  several  briefings  and  maintain  communication 
with  one  or  more  distributed  team  members  in  order  to  stay  aware  of  changing  conditions.  The 
planner’s  expected  non-eognitive  and  eognitive  tasks  were  defined  prior  to  the  warfighter 
assessment  via  SME  input. 

3.4.1  Macrocognitive  Metrics 

Work  conducted  in  a  strategy  planning  session  is  heavily  cognitively  focused  with  an  emphasis 
on  individual  and  team  information  gathering,  analysis  and  knowledge  building.  Noble  and 
Letsky  (2003)  detail  a  methodology  and  metrics  for  evaluation  of  collaboration  effectiveness 
within  a  Command  and  Control  (C2)  environment.  Their  approach  focused  on  the  use  of  a 
Transactive  Memory  Model  (detailed  below). 

Surveys  and  other  instruments  were  conducted  at  specified  scenario  breakpoints.  The  intent  was 
to  produce  as  many  quantifiable  metrics  as  possible,  such  as  the  number  of  communication 
events  to  a  specific  team  member  or  device,  the  time  to  create  a  product,  or  a  planner’s  workload 
via  the  NASA  TLX.  Qualitative  metrics,  particularly  those  associated  with  cognitive  tasks,  were 
used  to  determine  for  instance,  “how  well”  a  planner  understood  the  operational  environment  or 
who  possessed  knowledge  important  to  his/her  task.  Qualitative  metrics  required  interviews  or 
survey  instruments  to  capture  the  planner’s  thought  processes  and  knowledge. 
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Measuring  “tools  that  collaborate”  was  more  easily  accomplished,  because  objectives  were  better 
defined.  That  is,  tools  share  data  to  facilitate  strategy  planner  knowledge  building.  Knowing  that 
data  has  been  exchanged  between  two  applications  can  easily  be  accomplished.  Understanding 
how  well  each  application  takes  advantage  of  that  information  exchange  to  support  strategy 
planner  knowledge  building  is  more  difficult  and  was  not  considered  a  part  of  this  evaluation. 


3.4.2  Transactive  Memory  Model 

The  transactive  memory  model  (Figure  5)  for  collaboration  has  been  developed  and  tested  over 
the  past  fifteen  years  by  a  team  of  researchers,  Moreland,  Argote  and  Ingram,  from  the 
University  of  Pittsburgh,  Carnegie  Mellon  University  and  Columbia  University,  respectively 
(Liang  et  al,  1995;  Moreland  and  Myaskovsky,  2000;  Argote  and  Ingram,  2000).  Because  of  its 
emphasis  on  individual  and  team  cognition  and  its  strong  empirical  foundation,  this  model  has 
been  especially  useful  in  identifying  powerful  collaboration  metrics. 

The  transactive  memory  itself  consists  of  the  collection  of  individual  understandings  and  the 
team  mechanisms  to  exchange  information  and  so  update  these  individual  understandings.  The 
individual  understandings  include  all  of  the  understandings  about  teamwork  and  taskwork 
pointed  out  in  the  teamwork/taskwork  model.  These  include  understanding  how  to  do  the  tasks 
required  to  perform  the  mission,  understanding  the  status  of  the  situation  and  task,  understanding 
how  the  team  is  organized  to  function,  and  understanding  how  the  team  is  actually  functioning.  It 
includes  the  common  ground  elements  such  as  understanding  of  other  team  member’s 
capabilities,  workload,  and  knowledge. 


Feedback 


Figure  17  Transactive  Memory  Model 
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A  key  element  of  this  model  is  its  inclusion  of  the  understandings  found  in  the  Teamwork  and 
Taskwork  model.  Teamwork  is  defined  as  “the  additional  work  that  the  team  must  do  in  order  to 
function  as  a  team”  and  Taskwork  is  defined  as  “the  work  that  the  team  must  do  to  accomplish 
its  mission,  ignoring  the  coordination  and  other  additional  work  that  arises  from  working  as  a 
team”.  The  definitions  of  Taskwork  and  Teamwork  parallel  the  definitions  of  Work  and  Meta- 
Work  provided  in  Work  Centered  Design  by  Eggleston  (2003)  respectively.  Work  Centered 
Design  (WCD)  principles  have  been  foundational  in  design  principals  used  by  the  HE  in  the 
AOC  program  since  2004.  Noble  and  Letsky’s  (2003)  parallel  approach  provides  proven  metrics 
extended  across  distributed  collaboration  boundaries  to  assess  overall  collaboration 
effectiveness. 

This  methodology  provides  a  solid  measurement  of  the  overall  collaboration  and  toolsets  abilities 
to  ensure  effective  collaboration,  but  stops  short  of  allowing  association  of  benefits  and 
detriments  to  particular  tools.  Therefore,  the  addition  of  work  activity  monitoring  in  the 
collaboration  environment  is  important.  By  monitoring  user  activity  during  the  specified 
measurement  interval,  correlation  of  user  methodology  to  successes  and  failures  can  be  inferred. 
Post  mortem  processing  of  this  data  correlated  to  interval  survey  results  supplemented  with 
follow-up  user  confirmation/clarification  of  inferred  results  allow  for  better  understanding  of 
individual  capability  contributions  and  issues. 


3.4.3  Defining  Work  Activities 

USAF  military  subject  matter  experts  (SMEs)  developed  a  strategy  plan  based  on  a  pre-defmed 
scenario  which  explores  as  many  aspects  as  possible  of  the  collaborative  tools  and  technologies, 
while  exploring  system  boundary  conditions  and  affordances.  The  team  matched  activities  from 
the  strategy  planning  session  to  best  demonstrate  the  primary  aspects  of  the  tools  and 
technologies  and  stress  the  operational  characteristics  of  distributed  collaboration. 
Macrocognitive  processes  were  associated  with  major  elements  of  the  scenario  and  an 
appropriate  metric  applied  per  the  four  collaboration  stages  described  in  Section  3.3. 

Table  2  shows  the  majority  of  the  work  threads  performed  by  Strategy  Planners  during  CO  A 
analysis  is  primarily  manual  methods  of  information  exchange  such  as  whiteboards  or  printed 
maps.  These  methods  support  unstructured  stove-piped  functions  that  cannot  be  associated 
electronically  to  elements  of  the  plan  and  therefore  minimizes  essential  contextual  relationships 
from  which  true  information  can  be  derived. 


Table  2  Strategy  Planner  Work-Centered  Cognitive  Load  -  Meta-Work  (gray  cells)  and 
Intrinsic  Work  (white  cells) 


Strategy  Planner  Goals 

Strategy  Planner  Currently 

Current  IWPC  Strategy 
Tool  Provides 

Understand  cultures  and 
politics 

Uses  life  experience,  education, 
briefings 
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Understand  battlespace 

Is  provided  text,  overlays  or 
PowerPoint  slides  showing 
Restrictions,  No-Fly  areas, 
engagement  zones  etc. 

XML  Briefing  Composer 
(XBC)/  Enhanced 
Visualization  (eVis): 

Textual  data  and  maps, 
overlays  or  PowerPoint 
slides,  data  bases  that  do 
not  aggregate  the 
information 

Understand  guidance  and 
direction  provided  by 
higher  level  authorities 

Reads  text  based  documentation, 
maintains  majority  in  head  and 
shares  interpretation  verbally  with 
others  leveraging  white  boards  for 
collaboration 

Collaborative  Planning 

Tool  (CPT):  Textual  fields 
in  which  data  from  existing 
guidance  may  be  captured 
and  shared 

Maintain  awareness  of 
anticipated  location  of 
friendly,  adversary  and 
unaligned  forces 

Receives  PowerPoint  presentation  of 
information  from  ISRD, 
DIRMOBFOR  Staff  and  others 

CPT/Analyst’s 

Collaborative  Environment 
(ACE):  Query  tool  and 
folder  structure  for 
searching  MIDB  for  fixed 
target  locations 

Understand  target 
systems 

Must  already  be  trained  in 
understanding  the  interrelations 
among  elements  in  all  the  different 
types  of  Target  Systems 

Tel-scope/eVis:  Location, 
links  and  nodes,  alternate 
targeting  solutions 

Understand  weapon 
system 

Uses  life  experience,  education. 
Weapons  School,  briefings,  threat 
study,  etc 

Understand  weather  and 
environmental  impact 

Receives  briefings  on  climate,  reads 
reports 

Understand  constraints 
and  restraints 

Uses  life  experience,  education, 
briefings,  text  documents 

CPT:  Textual  capture  of 
data 

Understand  risk 

Seeks  out  subject  matter  experts, 
reads  text  reports 

Ensure  synchronization 
and  synergy  with  other 
members  of  COA 
Development  Team, 
superiors  and  other 
collaborators 

Uses  whiteboard,  paper  maps  and 
verbal  communication  commonly 
leveraged,  with  key  elements 
captured  into  PowerPoint  by  single 
individual  who  quickly  becomes 
overwhelmed 

Execution  Monitoring  Tool 
(EMT):  Synchronization  is 
provided  using  textual, 
concept  map  and  Gantt 
style  synchronization 
matrix  view 
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Track  sequence  of  actions 
required  to  take  place  in 
order  over  time  with 
criteria  for  the  start  of 
sequel  or  branch 
operations 

Use  numbered  textual  descriptions 
with  noted  times 

CPT/Electronic 
Synchronization  Matrix 
(eSync):  Hierarchical  tree 
view  of  plan  structure  or 
concept  map  structure  of 
plan  available  with 
temporal  display  using 

Gantt  style  synchronization 
matrix 

Establish  the  required 
Apportionment  levels  for 
each  COA  vs.  the 
available  resources  to  be 
apportioned 

Uses  manual  process  used  to  filter 
target  data;  identify  and  count  the 
number  of  desired  mean  points  of 
impact  (DMPI)  of  most  likely  target 
sets  (targets  of  type).  A  Spreadsheet 
Leveraging  known  resource  types  or 
gap  filling  with  proposed  resources, 
a  DMPI  Sortie  equivalent  is 
calculated  for  each  resource  and  an 
estimated  Apportionment  is  derived 
for  each  COA 

eVis:  Geographic  depiction 
of  targets  from  MIDB  and 
filtering  of  target  types 

Capture  reasoning  and 
intent  of  selected  COAs 
to  JFACC  and 
subsequent  Air  Tasking 
Cycle  process  managers 

Textual  and  PowerPoint  depictions 
of  each  COA  are  generated 

XBC:  Automated 
PowerPoint  generation  for 
the  textual  plan 
descriptions  captured 

Planners  work-around  these  limitations  by  aggregating  disparate  unstructured  sets  of  data  back 
into  a  PowerPoint  presentation  and  the  Information  Warfare  Planning  Capability  (IWPC) 
plarming  tool  to  re-associate  context  and  meaning  from  the  COA  development  process.  While 
IWPC  acts  as  a  repository  for  the  aggregation  of  much  of  this  data  into  a  structured  data  format, 
the  tool  is  not  commonly  used  interactively  during  the  development  of  a  COA.  The  fidelity  of  the 
IWPC  data  model  is  also  lacking,  textual  descriptions  are  commonly  used  vs.  discrete  elements 
and  attributes  throughout  the  tool,  forcing  human  cognition  of  meaning  vs.  system  processing 
into  human  perceivable  contextual  relationship  visualizations.  It  is  this  disconnect  between  the 
human  work  process  and  available  tools  which  was  addressed  with  the  integration  of  COA 
Sketch  and  other  work-centered  tools  that  collaborate  into  the  collaboration  environment. 


3.5  Building  the  Collaboration  Environment 

The  assessment  focused  on  distributed  AOC  strategy  planning  personnel  in  a  work-centered  and 
natural  collaboration  environment.  The  project  leveraged  the  main  LiveSpaces  features  and 
intended  to  identify  opportunities  for  new  features  specifically  tailored  to  support  a  USAF 
planning  construct.  For  this  study,  some  capabilities  were  omitted  and  some  were  changed,  for 
example  video  teleconference  was  replaced  with  a  less  expensive  alternative,  webcams. 

The  LiveSpaces  environment  was  configured  for  the  assessment  with  the  following  features: 
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1 .  Camera  Streaming  and  Audio  Chat 

2.  Presence  (User  activity  monitor) 

3.  Jabber  Chat 

4.  Screen  Sharing 

g.  Make  accessible  to  self  another  user’s  screen 

h.  Make  accessible  to  another  user  own  screen 

5.  Electronic  Whiteboard  (see  www.e-beam.com) 

6.  File  Sharing  /  Link  Sharing 

i.  Post  and  access  link  for  team  use 

7.  Shared  Clipboard 

j.  Post  or  pull  down  information  from  a  team  notepad  (text  only) 

8.  Collaborative  Editing 

k.  Three-tier  team  “document”  space  (Observe,  Propose,  Edit) 

9.  Live  Point/Synergy 

10.  Image  Management 

11.  Information  Ticker 

LiveSpaces  capabilities  which  were  not  instantiated  for  this  assessment,  a  USAF  distributed 
strategy  planning  context  included  the  following: 

1 .  Meta  applications,  room  session  management,  and  multi-media  playback 

2.  Projector  control  and  video  switching 

3.  Ignite  room  control  panel 

4.  Information  Repository 

While  the  aforementioned  capabilities  are  important  for  a  full  implementation  of  LiveSpaces, 
this  assessment  had  neither  the  resources  to  acquire  the  equipment  necessary  for  a  full  system, 
nor  the  time  to  setup  and  conduct  an  assessment  exercising  the  full  system. 

The  suite  of  strategy  planning  tools  available  to  the  strategy  planners  included  COA  Sketch  to 
support  the  Joint  Air  Estimation  Process  (JAEP)  products  through  COA  development  and 
Subject  Matter  Analysis  and  Research  Toolkit  (SMART)  to  collect,  organize  and  manage 
information  relevant  to  Mission  Analysis.  Technologies  such  as  COA  Sketch  and  SMART 
support  the  AOC  strategy  planning  process  and  have  been  instantiated  through  numerous  subject 
matter  expert  (SME)  interviews  and  collaborative  interactions  for  multiple,  concurrent  users 
within  and  across  those  technologies.  Further,  the  standard  suite  of  Microsoft  Office™  tools  such 
as  PowerPoint,  Word  and  Excel  were  available  on  workstations. 

COA  Sketch  provides  an  environment  to  develop  planning  elements  within  a  geographic  and 
temporal  context  (see  Figure  3).  Further,  strategy  planners  are  able  to  visually  initiate  the 
planning  process  and  drive  a  more  collaborative  and  cohesive  interchange,  enabling 
understanding  of  horizontal  and  vertical  nesting  of  objectives,  priority  effects,  and  operations. 
COA  Sketch  is  a  multi-user  tool  with  attribute  level  locking  and  near  real-time  data  updates 
which  enables  several  users  to  work  on  a  single  plan  simultaneously,  and  further,  observe  how 
others  are  contributing  to  plan  development.  COA  Sketch  emphasizes  moving  unstructured  data 
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from  the  selected  human-to-human  collaboration  environment  into  structured  information  sets 
realized  within  Community  of  Interest  (COI)  specific  supporting  tools. 


Figure  18  COA  Sketch  Workspace,  Sketch  &  Synchronization  views 

SMART  was  developed  under  the  Air  Force  Research  Laboratory  711  HPW/RHX  Commanders’ 
Predictive  Environment  (CPE)  proje  ct  and  is  the  culmination  of  an  inve  stigative  effort  initially 
conceived  to  ensure  adequate  context  for  person-  to-person  information  requests.  While  retaining 
its  original  functions,  SMART  evolved  to  a  res  earch  and  analysis  system  to  support  hum  an- 
centered  sem  antic  content  au  thoring  as  a  m  cans  to  trans  ition  web  c  ontent  to  se  mantic  web 
content.  Using  SMART,  one  can  embed  dom  ain-specific  knowledge  in  both  personally  authored 
and  retrieved  documents.  SMART  aids  users  to  locate  both  personal  expertise  (content  authors) 
and  knowledge  sto  res  (authored  co  ntent)  with  in  accessible  data  repo  sitories,  to  link  concep  ts 
shared  am  ong  disparate  research  threads,  and  to  maintain,  track,  and  in  tegrate  individual  and 
collaborative  lines  of  inquiry. 

Efficient  and  effective  predic  tion  in  an  organization  relies  on  efficient  knowledge  flow.  The 
desire  for  efficient  know  ledge  flow  is  echoed  aero  ss  the  range  of  com  puter  users,  but  especially 
by  information  analysts,  whose  daily  ef  forts  entail  intensive  search  and  filtering  to  dis  till  the 
relevant  from  the  prevalent  (Badalamente,  2003).  With  the  creation  and  deployment  of  advanced 
models  to  support  decisions  and  predictions  within  operating  environments  such  as  threat  models 
and  behavior  influence  models,  the  need  for  seamless  information  access  and  fusion  is  reinforced 
as  a  means  populate  models,  execute  models,  and  maintain  models.  Seamless  information  access 
and  rich,  diverse  inform  ation  fusi  on  and  exchange  is  what  the  Sem  antic  W  eb  aim  s  to  provide 
(Shadbolt,  2006). 

Earlier  Subject  Matter  Expert  (SME)  evaluations  including  WAIT-C  events  led  us  to  believe  that 
the  SMART  tool  shows  great  prom  ise  for  use  during  Intelligence  Preparation  of  the  Operational 
Environment  and  other  Mission  An  alysis  activities.  Of  primary  focus  was  particip  ant  usage  of 
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the  SMART  search  capabilities  for  discovery  of  information  sources,  notebook  organization  and 
sharing  throughout  team  s  and  the  use  of  the  provided  tagging  capabilities  for  capturing  of 
unstructured  data  elements  into  structured  data.  Participant  feedback  on  the  utility  o  f  Machine- 
to-Machine  (M2M)  tran  sfer  of  the  tagged  artifa  cts  between  the  SMART  and  COA  Sketch  too  Is 
also  are  a  collection  focus  point. 

Likewise  it  has  been  anticipated  through  equivalent  SME  f  eedback  that  the  COA  Sketch  tool 
would  most  likely  be  em  braced  by  p  articipants  in  capturing  geospatial  artifacts  prev  iously  only 
found  in  whiteboard  sketches  translated  into  PowerPoint  slides. 


3.6  SPVT  Collaboration  Technology  Assessment  Structure 

The  SPVT  Collaboration  technology  assessment  event  was  held  September  14-18,  2009  at 
distributed  locations  -  SRA  in  Dayton,  OH,  and  Louisiana  State  University  -  Shreveport  (LSU- 
S)  in  Shreveport,  LA.  The  collaboration  event  was  conducted  to  provide  the  Air  Force  Research 
Laboratory  (AFRL)  a  better  understanding  of  distributed  collaboration  technology  effectiveness 
in  a  USAF  AOC  Strategy  Division  planning  context. 

SPVT  Collaboration  event  participants  represented  a  breadth  of  experience  across  the  AOC 
including  strategy,  operational  assessment,  combat  operations,  influence  operations  and 
intelligence.  The  participants  were  a  mix  of  active  duty  and  retired  USAF  personnel  and 
government  contractors.  Conducting  a  true  distributed  collaboration  event  enabled  participation 
of  SMEs  from  the  608  AOC  who  otherwise  would  have  been  unable  to  attend.  Figure  1  shows 
the  distribution  of  participants  for  the  event  and  the  event  locations. 


Figure  19  Collaboration  Event  Participants  and  Event  Locations 
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The  SPVT  Collaboration  event  was  struetured  around  a  USAF  AOC  Strategy  Planning  scenario. 
Eight  SMEs  participated  in  the  event.  Four  SMEs  were  located  at  the  Dayton  site  and  four  SMEs 
at  the  LSU-S  site  (see  Figure  2).  Two  teams  were  established,  each  team  containing  two  SMEs 
from  each  site  to  maximize  the  potential  for  collaboration.  The  teams  conducted  Mission 
Analysis  and  COA  Development  for  a  Pacifica  scenario  adapted  to  enhance  collaboration  touch 
points.  Stew  Greathouse  (SG  Consulting,  EEC)  developed  a  script  and  modification  of  the 
required  Pacifica  scenario  to  provide  realistic  battle  rhythm  and  artifacts  for  the  event.  Mr. 
Greathouse  also  provided  white  cell  support  (J2  and  JFACC)  during  the  event,  as  required.  SRA 
provided  trainers,  tech  support,  and  facilitators  at  both  sites.  Training  was  provided  to  the  ESU-S 
site  via  the  Eivespaces  environment. 


Figure  20  Collaboration  Event  Setup 

The  event  was  carried  out  over  five  days  with  Day  One  focused  on  setup  (ESU-S  site)  and 
environment  familiarization  (Dayton  site).  Days  Two  through  Four  focused  on  continued 
familiarization,  event  execution  and  report  out  and  Day  Five  on  way  ahead  (subset  of  SMEs). 
The  primary  activities  occurred  on  Days  two  through  four.  SME  schedules  did  not  line  up 
exactly  with  the  event  script.  Scheduling  conflicts,  particularly  for  608  AOC  participants,  meant 
some  SMEs  arrived  throughout  Tuesday.  The  following  outline  reflects  roughly  the  intended 
event  script.  Deviations  from  this  script  occurred  as  required  to  accommodate  SME  schedules. 
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Day  1  AM 

Travel,  Environment  Familiarization 
Day  1  PM 

Environment  Familiarization 

•  Training 

o  COA  Sketch 
o  Livespaces 
o  SMART 
o  Other  items 

•  Free  Play  /  scenario  discussion 

Day  2  AM 
Mission  Analysis 

•  Exercise  Control 

o  Welcome 

o  Focus  on  collaboration  via  JAEP 
o  SMEs  act  as  support  staff 

o  SMEs  playing  roles  (JFACC,  Chief  of  Strategy,  etc)  will  do  what  their  role 
requires  to  continue  the  assessment,  but  are  not  the  focus  of  the  assessment 

•  Start  work 

o  White  Cell  issues  the  Warning  Order  (Pacifica/5.0  White  Cell  Documents/  2009 
SRA  WAIT-C  CFC  WARNORD_DRAFT.doc) 
o  Players  parse  the  Warning  Order  and  look  through  their  provided  documents 
o  The  ‘JFACC’  provides  guidance;  emphasizes  he  expects  five  days  operational 
warning  (however  the  Draft  Campaign  plan  mentions  only  48  hours  operational 
warning 

o  The  players  (should)  explore  this  disconnect  and  ultimately  find  the  ‘2009  SRA 
WAIT-C  CFC  Campaign  Plan  FINAL’  (in  one  player’s  document  store) 

■  !  This  disconnect  should  have  prompted  the  players  to  engage  in  the 

macrocognitive  behavior  -  “Shared  hidden  knowledge’’ 


Table  3  Mission  Analysis  Process  Used  During  the  Event 


Type  Mi 

ssion 

Analysis 

Item  Source 

Document 

Input 

JFC  Mission 

Provided 

1.  Player  Generic  Documents/2.0 
JFC  Plans/2009  SRA  WAIT-C 

CFC  Campaign  Plan.doc 

Input 

JFC  Intent 

Provided 

5.0  White  Cell  Documents/  2009 
SRA  WAIT-C  CFC 

WARNORD  DRAFT.doc 

Input 

Friendly  COG 

Provided 

1.  Player  Generic  Documents/2.0 
JFC  Plans/2009  SRA  WAIT-C 

CFC  Campaign  Plan.doc 
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Type  Mi 

ssion 

Analysis 

Item  Source 

Document 

Input 

Enemy  COG 

Provided 

1.  Player  Generic  Documents/2.0 
JFC  Plans/2009  SRA  WAIT-C 

CFC  Campaign  Plan.doc 

Input 

Fact 

Generated 

Players  cull  from  canon 
documents 

Input 

Assumptions 

Generated 

No  template  necessary 

Input 

JFACC  Tasks 

Provided 

PACIFICA/1.  Player  Generic 
Documents/2.0  JFC  Plans/2009 
SRA  WAIT-C  CFC  Campaign 
Plan.doc 

Input 

JFACC 

Guidance 

Provided 

Participation  in  the  process 

Output 

Essential 

Tasks 

Generated 

Output 

JFACC 

Mission 

Generated 

Output 

MA  Brief 

Generated 

Output 

JFACC  Intent 

Generated 

Output 

JFACC 

Guidance 

Provided 

5.0  White  Cell  Documents/White 
Cell  Inputs.doc 

Day  2  PM 

Mission  Analysis  Brief 

•  Mission  analysis  briefing  prepared  by  the  players  (Mission  Analysis  Teniplate_UP.ppt) 

•  Mission  analysis  briefing  presented  by  the  players 

Commander  Approves  Mission  Analysis 

•  Mission  Statement 

•  Commander’s  intent 

•  JFACC  issues  CO  A  Guidance  and  Commander’s  Comparison  Criteria  (White  Cell 
Inputs.doc) 

•  JFACC  requests  that  players  provide  a  Center  of  Gravity  Analysis  of  the  Califon  IADS 
(White  Cell  Inputs.doc) 

Hotwash  /  Elicitations 

•  Site  report  out  on  environment  challenges  and  affordances 

•  Players  comments  and  observations 

Day  3  AM 
COA  Development 
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•  COA  Comparison  Criteria  Discussion  -  The  players  ought  to  pick  apart  the  criteria  /  or 
request  further  guidance.  The  basic  guidance  is  one-word  descriptions  and  leading 
questions  (White  Cell  Inputs.doc) 

•  During  COA  development  players  start  to  look  at  the  Califon  IADS  (IPOE.doc) 

o  Elicit  macrocognitive  behavior  “Individual  mental  model  construction” 

•  COA  Development  begins  via  COA  Sketch 


Table  4  COA  Development  Process  Used  During  the  Event 


Type  COj^ 

Development 

Item  Source 

Document 

Input 

Enemy 

COAs 

Provided 

1.  Player  Generic  Documents/ 1.0 

Spin  Up  scenario/IPOE 

COA  Sketch  version  of  Califon 
COAS 

Input 

Staff  Est 

Provided 

1.  Player  Generic  Documents/3.0 
Mission  Analysis/  2009  SRA  WaitC 
Initial  Force  Structure.doc 

1.  Player  Generic  Documents/ 1.0 

Spin  Up  scenario/FROB 

Output 

Crit  Vuln 

Generated 

Output 

Alt  COAs 

Generated 

Output 

OP  &  Tac 
Obj 

Generated  SMI 

i  Start 

Output 

COA 

Sketch 

Generated  COj^ 

1  Sketch 

Output 

COA 

Statement 

Generated  COi^ 

L  Brief 

Output 

Crit  Events 
/  Actions 

Generated 

1.  Player  Generic  Documents/3.8 
COA  Analysis  and  Wargaming/ 
Wargaming  WS.xls 

Day  3  PM 

COA  Development  (cont’d) 

•  COA  Development  continues 

Hotwash  /  Elicitations 

•  Site  report  out  on  environment  challenges  and  affordances 

•  Players  comments  and  observations 


3.7  Data  Collection 

Information  capture  for  the  event  included:  Subjective  user  surveys  administered  at  the  end  of 
each  session  breakpoint,  technology  usage  statistics  (captured  via  computer  instrumentation), 
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observer  notes,  and  comments  collected  during  a  daily  hotwash.  The  quantitative  data  on 
technology  usage  was  collected  for  specific  technologies  at  each  workstation.  The  time  reflected 
the  “technology”  was  in  focus.  Data  were  collected  on  the  collaboration  environment,  i.e. 
Livespaces,  collaboration  technologies,  i.e.  COA  Sketch  and  SMART,  and  standard  workstation 
applications,  i.e.  Internet  Explorer,  PowerPoint  and  other  common  desktop  applications. 


3.8  Livespace  Configuration 

The  Livespace  configuration  consisted  of  three  large  public  displays  shared  by  the  team  at  each 
site.  Individual  workstations  were  configured  to  access  the  shared  displays  as  well  as  each 
other’s  individual  workstation,  when  necessary.  The  LivePoint  capability  allowed  for  ready 
movement  between  user  designated  displays  normally  only  consisting  of  the  shared  displays  (see 
Figure  3).  LivePoint  allows  user  mouse  and  keyboard  control  to  move  to  the  selected  machine 
simply  by  moving  one’s  mouse  through  the  edge  of  a  local  display  and  onto  the  display  of  the 
other  computer. 


>  Left  screen  shows  what  Is 
driving  the  work  -  “Battle 
Rhythm” 

>  Center  screen  is  the  main 
work  area  where 
collaborators  work  together 
to  build  product 

>  Right  screen  is  used  as  a 
shared  “scratchpad”  where 
users  can  share  personal 
artifacts,  reference 
documents  and  partial  work 
products 


Figure  21  Typical  LiveSpace  Shared  Display  Configuration 

The  collabo  ration  study  focused  on  the  inform  ation  exchanges  of  AOC  strategy  planners  and 
intelligence  analysts  within  a  work  cente  red  collaboration  environment.  In  theo  ry,  by  allowing 
these  users  to  interact  using  the  intuitive  extended  LiveSpaces  environment  and  by  allowing  the 
manipulation,  tracking  and  production  of  work  pr  oduct  objects  and  attribut  e  details  during  the 
collaboration,  effective  distributed  communication  would  occur. 
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Figure  22  Collaboration  Technologies  in  Use 
(Top  View  SRA  Dayton,  Bottom  View  LSU  Shreveport) 
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4  RESULTS  AND  DISCUSSION 


4.1  Approach 

This  is  the  first  time  I've  been  on  another  person's  computer  in  another  city  and  another 
state.  The  capability  is  useful,  despite  some  latency/bandwidth  issues.  I  liked  it  enough  to 
want  morel  ’’(comment  from  assessment  participant) 

Data  collection  consisted  of  user  feedback  on  technology  applicability  and  effectiveness, 
objective  measures  of  teehnology  use,  and  observations  of  technology  use.  The  following 
seetions  describe  in  greater  detail  the  measurement  tools,  data  and  analysis. 


4.2  Subjective  Data  Collection  Survey 

Surveys  were  administered  at  the  end  of  session  breakpoints,  i.e.  following  the  morning  session 
(am)  and  the  afternoon  sessions  (pm).  The  intent  was  to  quantify  through  qualitative  instruments 
user  pereeptions  regarding  collaboration  tool  and  environment  effectiveness  for  the  various 
aspeets  of  the  strategy  planning  scenario.  Further,  information  probes,  particularly  those 
associated  with  cognitive  tasks,  were  established  to  determine  for  instance  “how  well”  a  planner 
understood  the  operational  environment  or  who  possessed  knowledge  important  to  his/her  task. 
Unfortunately,  the  diseontinuity  in  Qualitative  metrics  required  interviews  or  survey  instruments 
to  capture  the  planner’s  thought  processes  and  knowledge.  The  survey  questions  are  shown  in 
Addendum  A. 


4.3  Survey  Analysis 

Survey  results  were  eollected  for  twenty  participant-sessions  and  are  summarized  in  Table  5.  The 
data  were  summarized  by  event  day  and  question.  Specifieally,  average  score  was  caleulated  for 
each  day  by  question  with  attention  to  day  to  day  changes  in  seore.  The  survey  analysis  includes 
an  interpretation  of  score  for  each  question,  major  findings  and  selected  individual  comments. 
Experimenterss  followed  up  with  participants  for  clarification  on  responses  and  to  address 
ineomplete  responses,  as  required. 


Table  5  Survey  Results  by  Player,  Day  and  Question  (1  -  strongly  disagree,  7  -  agree) 


Day  Survey 

Question 

Wed,  D1 

12: 

1456'/ 

8  9  10 

22  A- 1 

5  5 ; 

5  5  6  4 

3 

22A-X 

22; 

13  5  4t 

.43  5 

22A-2 

45 ; 

5  5  4  4 

3  6 

22B 

76( 

5  5  6  5  t 

'566 

22B 

77' 

mil 

111 

21A-1 

66( 

5  5  64t 

21A-2 

67' 

76 

66^ 

1 

21B-1 

3  5  ; 

5  3  4  3  f 

455 

21B-2 

66( 

5  6  5  4  ( 

'646 

IIB 

65( 

5446t 

'645 
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12A 

52( 

i43  6e 

.522 

12B 

54( 

'■>311 1 

.6 

5 

llA 

5  5 ; 

>  6226 

.567 

Average 

5.21 

5.0  5.6 

4.8 

4.9 

4.7 

6.0 

5.4- 

1.3  5.4 

Thurs,  D2 

12; 

5456'/ 

8  9  10 

IIB 

66; 

>6165 

667 

llA 

77' 

11166 

.667 

12A 

42; 

5  6  4  2 

23  ( 

3 

12B 

66; 

>5116 

.6 

7 

22B-1 

65  ( 

5576 

66 

22B-2 

67( 

56 

77' 

77 

21A 

65( 

5644f 

666 

Average 

5.91 

5.4  5.7 

5.9 

6.0 

5.2 

5.8 

5.51 

5.7  6.6 

Delta,  D2- 
D1 

0.7  ( 

).4  0.1 

1.1 

1.1 

0.5 

0.2 

0.1 

1.4  1.2 

Major  Subjective  Survey  Findings 

The  following  items  represent  major  findings  identified  in  the  analysis  of  the  subjective  survey 
results  in  Table  3.  The  survey  questions  in  Section  4.2  focus  on  environment  and  tool 
(LiveSpaces,  COA  Sketch,  SMART)  utility  and  ease  of  use  as  well  as  assessment  training  and 
instructions. 


•  Individual  capabilities  improved  due  to  1)  improved  performance,  and  2)  experience  with 
tool  (suggests  more  training  may  have  been  helpful) 

•  The  overall  collaboration  environment  (LiveSpaces,  COA  Sketch  and  SMART 
capabilities)  was  rated  lower  than  the  average  of  the  individual  capability  ratings  - 
perhaps  due  to  an  interaction  based  on  cognitive  shifts  between  SMART  and  COA  and 
LiveSpaces 

•  Instructions  had  largest  Day-to-Day  improvement  due  presumably  to  environment 
stability  and  easier  time  for  players  to  focus  on  task 

•  SMART  (“helpful  in  this  session”)  was  the  only  negative  Day-to-Day  survey  response, 
most  likely  due  to  attempted  application  on  COA  (Day  2)  with  no  clear  direction  for  its 
use 

•  Large  improvement  Day-to-Day  among  tools  with  COA  Sketch  (helpful  in  session)  due 
to  correct  application  and  more  experience 

•  LiveSpaces  was  assessed  equally  well  across  Mission  Analysis  and  COA  Development 
(internal  validity  -  no  reason  to  believe  a  difference  exists  for  these  work  processes) 

•  The  environment  improved  Day-to-Day 

•  Lack  of  SME  at  LSU-S  hurt  training  support  (original  plan  was  to  conduct  via 
LiveSpaces,  but  environment  issues  derailed  that  plan  with  no  good  contingency) 

•  COA  was  well-received  despite  some  training  issues 

•  Training  on  Day  1  was  rated  lowest,  indicative  of  early  frustrations  with  environment 
performance  and  some  tool  usability  issues  (SMART  and  LiveSpaces) 
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•  Sub-teams  where  one  member  was  better  trained  on  a  tool  and  passed  along  that 
knowledge  to  other  team  members  performed  better 

Selected  Individual  Comments  form  Subjective  Surveys 

The  following  bullet  lists  represent  Positive  and  Not-so-Positive  individual  written  comments 
included  in  the  subjective  surveys.  Most  Positive  comments  were  capability  focused,  whereas 
most  Not-so-Positive  comments  were  LiveSpace  hardware  and  software  technology  stability 
focused. 

Positive 

•  "Most  useful  workshop  -  focus  on  tool  value  and  operational  process" 

•  COA  Sketch  was  the  easiest  application  to  use 

•  COA  Sketch  Synchronization  was  "awesome" 

•  Shared  documents  and  highlighting  was  helpful  (SMART) 

•  Searched  for  the  "right  mix"  of  attention  to  tools  versus  working  collaboratively 

•  Primary  data  search  (inter-document)  worked  well,  but  intra-document  was  less 
productive  (SMART) 

•  Environment  is  good  to  bring  transient  users  up  to  full  SA  quickly 

•  Working  on  COAs  at  the  same  time  was  helpful 

•  Political  analyst  thought  SMART  would  be  great  for  writing  a  report  -  highlight  was  a 
very  nice  feature 

•  SMART  capabilities  were  very  good,  but  some  implementation  was  not  intuitive; 
documentation  location  unknown 

Not  So  Positive 

•  System  instability  disrupted  work 

•  Tool  interoperability  needed  improvement 

•  Needed  more  training  time  -  too  much  functionality  to  learn  in  one  day  (perhaps  more 
read  ahead  materials) 

•  LiveSpaces  Clipboard  was  cumbersome 

•  The  “big  picture”  objective  was  not  clear  (hid  some  macrocognitive  functions) 

•  Manual  copying  and  pasting  into  PPT  is  a  "step  backwards"  -  after  using  the  environment 

•  Players  had  difficulty  maintaining  consistent  work  with  frequent  environment 
malfunctions 

•  Difficulty  with  audio  -  talking  to  person  at  side  (collocated)  and  on  headset  at  same  time 

•  Need  the  video  capability 


4.4  Direct  Observation  Analysis 

An  experimenter  was  assigned  to  observe  collaborative  interaction  for  two  participants  during 
the  assessment.  Each  experimenter  wore  a  headset  in  order  to  monitor  dialogue  among  the 
participants  and  recorded  observations  in  a  spreadsheet  as  the  observations  occurred.  The 
spreadsheet  was  originally  developed  specifically  for  association  with  the  predefined 
macrocognitive  metrics.  The  goal  was  for  the  observer  to  record  1)  the  time  of  the  observation, 
2)  the  observed  activity,  3)  the  participant(s),  4)  the  specific  capability  associated  with  a 
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technology  (LiveSpaces,  COA  Sketch,  SMART),  5)  the  observer,  6)  codes  to  denote  the 
presence  of  specific  collaborative  behaviors  or  attributes  such  as  individual  work  or  issue,  and  7) 
one  or  more  associated  macrocognitive  behaviors.  Analysis  of  the  observation  data  follows. 

Figure  8  shows  technology  use  (number  of  observed  occurrences)  across  assessment  planning 
activities  (Mission  Analysis,  COA  Creation,  IADS  COG  Analysis).  Much  of  the  Mission 
Analysis  was  performed  in  SMART.  Document  highlighting  for  export  to  COA  Sketch  was  a 
common  work  pattern  with  the  SMART  technology.  Users  commented  on  the  desire  to  extend 
the  highlight  and  publish  capability  to  other  JAOP-related  activities.  As  expected,  COA  Sketch 
was  the  primary  technology  used  to  aid  the  COA  Creation  process.  Both  technologies  wee 
equally  useful  during  the  IADS  COG  Analysis. 


Usage  of  COA  Sketch  /  SMART 


- CO  A  Sketch 

- - SMART 


Assessment  Hour 


Figure  23  COA  Sketch  and  SMART  Use  by  Activity 

Figure  9  shows  LiveSpace  capability  use  (number  of  observed  occurrences)  across  assessment 
planning  activities.  Screen  sharing  proved  to  be  the  most  used  capability  (by  an  order  of 
magnitude).  Screen  sharing  provided  a  real-time  awareness  of  other  on-going  activities  during 
the  strategy  planning  sessions.  Co-located  team  members  tended  to  use  the  shared  space  to  talk 
through  discovered  information  and  questions.  The  overview  by  the  White  Cell  JFACC  and  other 
team  members,  both  co-located  and  distributed,  were  commonly  followed  along  with  shared 
screens  or  clicking  through  elements  in  a  shared  application  presentation,  for  example,  COA 
Sketch. 
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Livespaces  Usage 


- Shared  Clipboard 

- Link  Sharing 

- Screen  Sharing 
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Figure  24  LiveSpace  Capability  Usage 

Figure  10  shows  LiveSpace  capability  use  (number  of  observed  occurrences)  across  assessment 
planning  activities  with  a  scale  expanded  to  show  differences  between  all  capabilities  other  than 
Screen  Sharing.  In  this  case,  Shared  Clipboard  was  the  second  most  used  capability.  Team  Think 
and  Link  Sharing  were  the  next  most  used  capabilities,  occurring  at  roughly  equal  but  different 
times  during  the  assessment,  suggesting  these  capabilities  may  complement  one  another. 
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Livespaces  Usage  w/o  Screen  Sharing 


Assessment  Hour 


Figure  25  LiveSpace  Capability  Usage  (expanded  scale) 

Figure  1 1  shows  the  number  of  observed  performance  issues  in  the  collaboration  environment  as 
a  function  of  time  during  the  assessment.  The  graph  shows  the  instances  where  interruptions  in 
the  LiveSpaces  environment  early  in  the  assessment  led  to  an  inability  to  conduct  work  for  two 
to  three  hours  while  the  teams  developed  workarounds.  Dependability  of  the  collaborative 
infrastructure  will  need  to  be  a  primary  focus.  Post-event  analysis  determined  that  a  federated 
LiveSpace  capability  would  have  greatly  improved  performance  with  respect  to  Live  Point 
issues.  Additional  improvements,  however,  could  be  implemented  through  redundancy  of 
capabilities,  i.e.  Audio  and  Text  Chat.  Continuity  of  operations  is  extremely  important  during 
strategy  planning. 
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Usage  of  COA  Sketch  /  SMART 


COA  Sketch 

SMART 

Issues 
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Figure  26  Technology  Performance  Issues  During  the  Assessment 
4.5  Macrocognitive  Analysis 

The  team  identified  key  elements  of  the  pre-defined  strategy  planning  scenario  which  could  be 
associated  with  macrocognitive  processes  and  applied  per  the  four  collaboration  stages  described 
in  Section  3.3.  Scenario  stimuli  were  created  for  several  macrocognitive  processes  such  that 
when  a  specific  event  occurred  during  the  scenario,  the  team  could  observe  activity  and 
determine  whether  the  collaborative  behavior  occurred.  Unfortunately,  instabilities  in  technology 
performance  resulted  in  the  strategy  planning  teams  creating  workarounds  which  in  some  cases 
bypassed  the  scenario  stimuli.  Additionally,  these  instabilities  sometimes  disabled  the  technology 
medium  through  which  the  stimuli  was  to  be  communicated. 

In  one  instance,  a  scenario  stimulus  to  test  the  macrocognitive  process  “Individual  visualization 
and  representation  of  meaning”  was  presented  by  the  JFACC  to  the  team  via  a  message  ticker  on 
the  shared  display.  The  information  was  noticed  quickly  by  one  team  member  and  communicated 
to  the  rest  of  the  team.  Although  only  a  single  example  of  a  scenario  stimulus  and  a 
macrocognitive  process  demonstrating  collaborative  behavior,  the  approach  proved  useful  and 
the  environment  affordances  were  observed. 

Future  studies  could  leverage  the  design  for  scenario  stimuli  and  macrocognitive  process  probes. 
The  observation  data  in  Addendum  B  provides  indicators  of  macrocognitive  process  behaviors, 
however,  those  indicators  are  inconsistent. 
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4.6  Overall  Analysis 

The  analysis  of  surveys,  interviews  and  observational  data  led  to  the  following  conclusions 
regarding  the  overall  effectiveness  of  the  collaboration  environment: 

•  Participants  believed  tools  facilitated  team  building 

•  Participants  believed  the  environment  provided  flexibility  to  pursue  parallel  operations 

•  Participants  cited  the  need  for  establishing  new  concepts  of  operation  for  use  of  the 
environment 

•  While  glimpses  of  intense  collaboration  were  seen,  the  lack  of  true  time  pressure  and 
experience  level  of  key  participants  appeared  to  control  the  level  of  intensity 

o  Indications  are  the  environment  was  conducive  to  support  intense  collaboration 

•  Much  of  the  mission  analysis  was  performed  using  the  SMART  tool 

o  Highlighting  of  documents  for  export  to  COA  Sketch  was  a  common  work  pattern 
o  Users  wanted  to  extend  highlight  and  publish  capability  to  capture  JAOP 
information 

•  Screen  sharing  proved  to  be  the  most  used  capability 

o  Used  primarily  as  a  real-time  awareness  of  what  else  was  being  done, 
o  Collocated  team  members  tended  to  use  the  shared  space  to  work  through 
discovered  information  and  questions 

o  Overview  by  White  Cell  JFACC  and  other  team  members,  both  collocated  and 
distributed,  was  commonly  followed  along  with  shared  screens  or  clicking 
through  elements  in  shared  application  presentation  (COA  Sketch) 

“I  could  see  things  popping  into  COA  Sketch,  so  we  knew 
stuff  was  getting  done  and  what  others  were  doing,  which  de- 
conflicted  team  editing  efforts  ” 

•  COA  Sketch  became  the  centralized  aggregation  point  for  information  and  was  only 
transferred  to  PowerPoint  to  fulfill  the  requirement  for  a  briefing  format 

o  Users  liked  immediate  display  of  what  everyone  was  doing  in  the  tool 
o  Geospatial  query  of  data  such  as  provided  by  GCCS  13  would  enhance  utility 
o  COA  Sketch  was  cited  as  supporting  6  month  to  2  year  planning  while  also 
having  the  capability  to  support  Crisis  Action  Planning 

•  Multi-user  editing  (both  simultaneous  and  sequential)  occurred 

o  Teams  frequently  used  a  mixed  simultaneous/sequential  process  with  a  gather  and 
approve  methodology 

■  Putting  information  in  the  Shared  Clipboard  for  sharing  in  PowerPoint 

■  Use  of  shared  notebooks  in  SMART 

■  Distributed  team  updates  to  COA  Sketch 

o  Group  collaboration  to  bring  together  independent  products 
o  Good  central  awareness  and  participation  both  locally  and  remotely  for  validation 
of  facts 

o  COA  Sketch  opened  remotely  using  LivePoint  &  Screen  Sharing  to  update 
PowerPoint  brief 
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•  Participants  appeared  to  easily  understand  the  LivePoint  feature 

o  The  participants’  early  dependence  on  this  feature  was  easily  recognized  when 
this  feature  was  later  unavailable 
o  This  feature  was  used  by  all  participants  once  re-established 
o  Structured  “radio  protocol”  announcing  taking  over  of  shared  displays  was 
established  as  a  process  by  the  teams  to  de-conflict  multi-user  control  conflicts 
o  Users  experienced  lost  cursors,  but  in  most  cases  were  able  to  recover  without 
intervention 

•  Team  members  had  a  propensity  towards  collocated  collaboration  with  “check-in”  to 
remote  organization 

o  Likely  a  direct  impact  of  the  lack  of  clean  audio.  During  times  of  good  audio,  the 
teams  seemed  to  work  together  more  frequently  using  the  shared  displays 
o  This  behavior  was  augmented  by  the  real-time  awareness  through  the  common 
displays  mentioned  above 

•  Use  of  eBeam  whiteboard  both  with  projection  and  standalone  worked  just  as  well 
distributed  as  collocated  and  was  embraced  by  the  participants 

o  “Note  Taker”  role  still  emerged  in  this  instance  to  ensure  ideas  were  available  to 
everyone  in  a  structured  format  (entered  through  COA  Sketch) 

•  Dependability  of  the  collaborative  infrastructure  was  a  primary  focus 

o  Overall  system  reliability  suffered  early  in  the  assessment  and  improved  with 
continued  attention  and  improvements 

o  Redundancy  of  capabilities  (i.e.  Audio  and  Text  Chat)  is  critical  to  ensure 
continuity  of  operations 

•  Ease  of  use  and  configuration  is  important 

o  Chat  pre-populated  with  users  was  better  than  having  to  find  users  (versus  past 
operational  experiences).  Established  rooms  for  types  of  discussions  also 
important 

o  Good  task  for  a  coordination  team  or  automation 

o  Availability  of  a  spellchecker  would  prove  useful  throughout  the  environment 
o  Allowing  Shared  Clipboard  data  (beyond  simply  text)  to  follow  LivePoint  mouse 
vs.  extra  clicks  of  current  shared  clipboard  was  desired 
o  Allowing  multi-user  concurrent  edit  into  separate  sections  of  a  document  was 
desired 

•  Video  capabilities  should  include  wide  angle  focus  and  wide  angle  (for  group  discussion) 
to  provide  a  larger  “context” 

The  following  dialogue  was  provided  by  one  of  the  participants,  an  intelligence  analyst,  with  a 
focus  on  environment  applications  outside  of  AOC.  These  inputs  include  providing  this  type  of 
workspace  to  convey  a  watch  office  (Operations  Center)  feel  to  one’s  desktop.  Further,  the 
capability  to  have  a  sidebar  room  present  while  attending  a  briefing  is  very  good  -  permitting 
people  to  collaborate  while  digesting  information. 

“As  so  often  the  understanding  of  a  country's  current  political  situation  involves— at  a 
minimum— an  awareness  of  its  military  situation,  it  becomes  incumbent  upon  the  political  or 
leadership  analyst  to  access  the  most  up-to-date  military  information  to  prepare  for 
meetings,  briefings,  and  position  papers.  It  would  be  especially  helplful  for  the  analyst 
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working  a  regional  hotspot,  a  country  where  a  coup  has  just  occurred,  where  there  is  a 
leadership  crisis  occurring— anything  that  requires  the  most  timely  information  from 
extremely  reliable  sources.  In  such  instances,  the  analyst  will  often  call  upon  the  expertise  of 
military  analysts  who  may  not  always  be  co-located,  and  this  [environment]  would  make 
simultaneous  communication  with  several  people  across  time  zones,  agencies,  bases,  etc. 
much  easier.  In  effect,  this  could  add  a  "watch  office"  type  of  feel  to  an  analyst's 
workstation,  allowing  instantaneous,  "raw"  information  to  be  shared/digested,  as  well  as 
access  to  the  more  formal  finished  reports,  translated  newspaper  articles,  etc.  that  the 
analyst  is  used  to  receiving. 

As  a  rather  simple— but  important— example,  this  could  save  on  driving  time  and  the 
difficulty  of  traveling  with  classified  information  for  in-town  inter-agency  meetings.  So 
often,  meetings  occur  in  conference  rooms  where  participants  bring  only  a  spiral  notebook 
(for  example)  and  have  limited  access  to  information.  In  cross-departmental  meetings,  this 
technology  would  allow  the  analyst  to  sit  at  his/her  desk  and  take  notes,  look  up  something 
quickly,  search  archived  papers/materials,  and  essentially  have  all  kinds  of  information 
readily  accessible  should  he/she  be  asked  a  question  or  to  contribute  something  they  were 
not  already  prepared  to  give.  The  chat  room  feature  is  wonderful,  also,  in  this  setting.  I 
liken  it  to  sitting  in  the  back  of  a  room  during  a  briefing  or  meeting  and  bouncing  off 
ideas/questioning  the  analysis  to  the  person  sitting  next  to  me.  It  doesn't  interrupt  the  flow  of 
the  meeting  or  the  speaker,  and  is  discreet. 

I  imagine  this  technology  would  allow  the  political  analyst  to  access  research  papers  and 
the  like  written  by  people  at  other  agencies  or  bases.  Oftentimes  we  had  to  wait  for  the 
published  article  to  reach  our  office,  which  could  be  days  or  weeks  depending  on  the 
classified  mail  system.  This  way,  other  peoples'  analyses  would  be  much  more  readily 
accessible.  I  always  sought  out  my  "competitor's" papers  and  views  on  an  issue  or  brewing 
situation  to  see  his/her  chain  of  logic,  sources,  and  conclusions.  ” 
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5  SUMMARY 


The  SPVT  Collaboration  Assessment  event  set  out  to  test  the  hypothesis  that 

“The  [LiveSpaces]  collaboration  environment  enables  a  distributed  strategy  plans  session 
which  is  as  effective  as  that  developed  by  collocated  planners,  ” 

The  assessment  was  determ  ined  using  a  com  bination  of  LiveSpaces,  COA  Sketch  and  SMART 
technologies.  LiveSpaces  contained  an  abbreviated  set  of  full  capabilities. 

5.1  TRUE  DISTRIBUTED  OPERATIONS 

The  SPVT  Collaboration  Assessment  event  provided  a  true  demonstration  of  distributed 
operations.  Two  separate  teams  of  four  strategy  planners  and  intelligence  analysts  conducted 
JAEP  activities  in  a  USAF  AOC  strategy  context. 


5.2  COLLABORATION  SYSTEM  AEFORDANCES 

The  LiveSpaces,  COA  Sketch  and  SMART  technologies  proved  to  have  great  potential  for  use  in 
distributed  planning  operations.  The  most  used  LiveSpaces  capabilities  were  LivePoint  and 
Screen  Sharing.  Primary  interactions  included  moving  to  or  exposing  a  display  in  order  to 
facilitate  discussion  or  to  take  command  of  an  activity  and  monitoring  other  displays  for 
individual  or  team  situation  awareness. 

COA  Sketch  was  the  main  aggregation  point  for  work  and  work  products.  Teams  developed 
geospatial  products  in  COA  Sketch.  Mission  Analysis  artifacts  were  passed  to  COA  Sketch 
through  a  web  service  to  SMART.  Users  particularly  liked  observing  updates  to  COA  Sketch 
work  products  in  near  real  time. 

SMART  quickly  became  the  tool  of  choice  for  conducting  mission  analysis.  The  highlighting 
and  source  documentation  features  were  most  used,  while  auto-populating  desired  COA  Sketch 
work  products  was  most  appreciated. 


5.3  COLLABORATION  SYSTEM  WORK-CENTERED  OPPORTUNITIES 

Several  known  and  some  newly  discovered  human  interface  and  work-centered  design  issues 
were  documented  during  the  assessment.  These  issues  suggest  a  need  for  additional  human 
factors  research  to  refine  the  capabilities. 

LiveSpaces  was  reported  to  be  quickly  and  easily  understood.  Further,  users  commented  on  the 
transparency  of  the  technology,  that  is  the  capability  was  minimally  visually  intrusive.  In  the 
case  of  LivePoint  and  Shared  Screens  (after  initial  setup),  user  operation  became  a  part  of  the 
work.  Users  commented,  however,  the  system  may  have  been  “too”  transparent,  indicated  by 
“unlabeled”  mouse  operations  on  shared  displays  where  users  could  easily  become  confused  on 
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who  was  controlling  the  display.  Further,  control  transfers  to  the  aetive  mouse  on  a  shared 
display.  So,  a  user  condueting  a  task  who  pauses  for  a  moment  to  collaborate  with  other  team 
members  eould  easily  lose  control  of  the  display.  The  eoordination  between  users  was  eontrolled 
through  a  “radio  protocol”  and  worked  effeetively  for  this  assessment  scenario,  but  additional 
study  could  produce  a  more  natural  work  method. 

SMART  reeeived  eomments  on  speeifieally  structuring  information  for  use  by  other  applieations. 
Mostly,  intelligenee  analysts  used  SMART  to  seareh  and  capture  information  for  population  in 
COA  Sketeh.  Strategy  planners  were  found  oceasionally  using  the  SMART  search  capability  to 
recall  or  identify  information  previously  or  reportedly  available  to  the  teams. 


5.4  COLLABORATION  SYSTEM  RELIABILITY 

Many  diseussion  points  brought  forth  by  the  users  regarding  the  eollaboration  system  were 
foeused  on  software  reliability.  Unfortunately,  the  LiveSpaees  software  implemented  for  the 
SPVT  Collaboration  Assessment  event  was  an  important  revision  behind  the  eurrent  operational 
software.  The  event  focused  on  eonneeting  two  LiveSpaees  between  distributed  sites  across  the 
internet.  Preliminary  testing  indieated  bandwidth  would  be  sufficient  for  the  event.  However, 
bandwidth  requirements  for  the  eustom  audio  and  video  eomponents  employed  in  LiveSpaees 
scaled  exponentially,  resulting  early  in  poor  audio  and  throughout  the  event  poor  video. 

Post-event  eommunications  with  DSTO  determined  that  a  newer  version  of  LiveSpaees  better 
handled  eommunieations  between  distributed  LiveSpaees  by  “federating”  sites  from  a  primary 
site.  Subsequent  tests  proved  the  newer  version  of  LiveSpaees  would  have  signifieantly 
improved  collaboration  system  performance. 


5.5  COLLABORATION  SYSTEM  ASSESSMENT 

In  general,  users  were  very  positive  about  the  potential  the  environment  afforded.  Users 
expressed  eoncem  initially  over  eapability  performance  issues,  but  quickly  worked  beyond  those 
issues,  an  indication  that  the  teehnology  affordanees  outweighed  the  operating  eost.  A  detailed 
assessment  of  how  powerful  the  teehnologies  could  be  was  difficult  to  obtain  because  multiple 
workarounds  were  in  plaee.  However,  as  users  beeame  more  familiar  with  the  teehnologies  and 
the  teehnologies  became  more  stable,  the  underlying  potential  began  to  surfaee. 

While  a  definitive  response  to  whether  the  assessment  hypothesis  is  “true”  or  “false”  is  diffieult 
to  determine  quantitatively,  many  qualitative  measures  indicate  the  environment  elearly  supports 
distributed  strategy  planning,  and  with  additional  eapability  refinements  and  performanee 
enhaneements  the  environment  would  meet  a  present  warfighter  need.  Warfighter  comments  on  a 
survey  (see  below)  offer  one  perspeetive  on  the  eollaboration  environment  that  appeared  to  be 
shared  across  participants. 
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Additioaal  Comments  or  Recommendations 
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7  ACRONYMS 


ACC 

AFRL 

AMC 

AOC 

API  Application 

BLOG  Web 

BOGSAT 

CMS 

COA 

COI 

COTS  Comm 

CRM  Custom 

DISA 

DoD 

DSTO 

GUID 

HE  Hum 

HPW  Hum 

HTML 

ISRD 

IWPC  Inform 

JAEP 

JAOP 

HPW  Hum 

SMART 

SME 

SPVT 

UI  User 

USAF 

USSTRATCOM 
XML  Extensible 
WCSS 


Air  Combat  Command 
Air  Force  Research  Laboratory 
Air  Mobility  Command 
Air  &  Space  Operations  Center 

Programming  Interface 
log 

Bunch  of  Old  Guys  Sitting  Around  the  Table 
Content  Management  System 
Course  of  Action 
Community  of  Interest 

ercial-off-the-Shelf 
er  Relationship  Management 
Defense  Information  Systems  Agency 
Department  of  Defense 

Defence  Science  and  Technology  Organisation 
Globally  Unique  Identifier 
an  Engineering 
an  Performance  Wing 
Hypertext  markup  Language 

Intelligence,  Surveillance  &  Reconnaissance  Division 
ation  Warfare  Planning  Capability 
Joint  Air  Estimate  Process 
Joint  Air  Operations  Plan 
an  Performance  Wing 
Subject  Matter  Analysis  Research  Toolkit 
Subject  Matter  Expert 
Strategy  Planning  Visualization  Tool 
Interface 

United  States  Air  Force 
United  States  Strategic  Command 
Markup  Language 
Work  Centered  Support  Systems 


E-44 


8  SUBJECTIVE  SURVEY 


FEEDBACK  FORM 

SPVT  Collaboration  Exercise 


Name: _ 

Session:  (circle  one)  Wed  am  Wed  pm  Thurs  am  Thurs  pm 
We  value  your  feedback! 

Instructions:  Please  rate  the  following  statements  with  respect  to  the  session  you  just  completed 
on  a  7-point  scale  with  1  representing  the  low  or  negative  end  of  the  scale  and  7  as  the  high  or 
positive  end  of  the  scale  and  provide  comments  to  support  your  rating  or  any  additional 
comments  pertaining  to  the  statement. 

Scale: 

1  =  Strongly  Disagree,  2  =  Disagree,  3  =  Moderately  Disagree,  4=  Neutral,  5  =  Moderately 
Agree,  6  =  Agree,  7  =  Strongly  Agree 

Questions  Ratings 

1 .  I  could  effectively  complete  the  tasks  and  scenarios  using  this  suite  of  1234567 
tools. 

Why/Why  not?  : _ 


2.  I  felt  comfortable  using  this  suite  of  tools  to  collaborate  with  my  team.  1  2  3  4  5  6  7 
Why/Why  not?  : _ 


3.  Livespaces  was  helpful  in  this  session. 
Why/Why  not?  : _ 


1  2  3  4  5  6  7 


4.  I  found  Livespaces  easy  to  use  during  this  session. 
Why/Why  not?: _ 


1  2  3  4  5  6  7 


5.  CO  A  Sketch  was  helpful  in  this  session. 

Why/Why  not?: _ 


1  2  3  4  5  6  7 
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1  2  3  4  5  6  7 


6.  I  found  COA  sketch  easy  to  use  during  this  session. 
Why/Why  not?: _ 


7.  SMART  was  helpful  in  this  session.  1  2  3  4  5  6  7 

Why/Why  not?  : _ 


8.  1  found  SMART  easy  to  use  during  this  session.  1  2  3  4  5  6  7 

Why/Why  not?  : _ 


9.  The  training  1  received  on  the  tools  was  adequate  for  me  to  use  them  1  2  3  4  5  6  7 

effectively  during  this  session. 

Comments: _ 


10.  The  instructions  for  this  study  were  clear  and  understandable. 
Comments: _ 


1  2  3  4  5  6  7 


Additional  Comments  or  Recommendations 


Thank  you  for  completing  this  feedback  form.n 
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